rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Erik & Frederick,
I half a 75% finished reply in my draft folder after reviewing the patch.
There is no technical reason to hold the patch (I like both the implementation and
the documentation), however there are two issues
which I believe should be considered: Even if I agree with Fredericks rule interpretation of
"having a route" I am sure that there will be other interpretations (especially if one generalizes
to all possible games and trains) and I would prefer to see a discussion at least on this list,
but it is even more likely that it should end up on the yahoo list.
>From a design point of view I agree with Eriks point of view that it should stay outside of the game engine,
however for different reasons... But here my opinion is not that important as the patch will not
make  into Rails 2.0 anyway.
So please be patient for more details.
Stefan



-----Ursprüngliche Nachricht-----
Von: "Frederick Weld" <fre...@go...>
Gesendet: Dec 30, 2011 11:17:21 AM
An: "Development list for Rails: an 18xx game" <rai...@li...>
Betreff: Re: [Rails-devel] Push request: Enforcement of forced train purchases

You are right that parts of the route calculation might be performed
twice. However:

(1) This only occurs if all other necessary conditions for forced
train purchases apply (see lazy route calculation in
OperatingRound.isForcedTrainPurchase).

(2) Even then, this duplication only applies to the initialization of
the network graph, as the second route determination is parameterized
differently with respect to trains (publicly available train types vs.
company owned ones (=zero) for triggering by the UI layer).

For the target design, I fully agree with you. The tricky part would
consist of avoiding duplication during graph construction and route
calculation, given that each OR-step is potentially based on a
different graph (eg., lay tile changes graph for lay token) and works
with different train sets (set revenue vs. forced train purchase).

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Frederick and others interested:

again thanks for your patch: However I would not apply it as it  for two main 
reasons. I have split my mail into two, because one targets
the question of rules and how to implement them and the next one which 
discusses in which layer of Rails it should be implemented and what the user
experience should be.

First I have to state that (at least from my point of view) there are the two 
possible implementations to check if a company has to purchase a train (for 
those games which require a valid route):

i) Check if there is a route that connects one home token of the company with 
another scoring node (which is a valid terminate for a train in this game).

or 

ii) Check if one would run the available train for purchase this train 
generates non-zero revenue on the existing network of that company.

Frederick has chosen the ii) and I used to intend to use the same approach, 
however my mind changed after reading some of the rules where the differences 
might matter. I would now suggest to check condition i) instead.

Other opinions here?

Stefan

Detailed discussion:

What is the definition of a "route"?

I had a few checks on those games that require a route according the rules 
difference list (http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm), it 
seems that most agree that a valid route exists of two "scoring nodes" (be it 
cities, towns, off-board areas).

1830(AH) for example defines it pretty clear in the first sentence of 20.1:
"A route is a length of track joining 2 or more cities." (Cities in 1830 rules 
include towns (small cities) and off-board areas).

However in 20.2  it states "Any Corporation which is operating must have at 
least one train during its turn of an Operating Round unless there is no route 
available on which it could possibly run."

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> i) Check if there is a route that connects one home token of the company
> with another scoring node (which is a valid terminate for a train in this game).
> 
> or
> 
> ii) Check if one would run the available train for purchase this train generates
> non-zero revenue on the existing network of that company.
> 
> Frederick has chosen the ii) and I used to intend to use the same approach,
> however my mind changed after reading some of the rules where the
> differences might matter. I would now suggest to check condition i) instead.
> 
> Other opinions here?

Intuitively, I would choose option i) as well,  if only to keeps things simple.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Regarding the definition of routes:
Thanks for pointing out that there are variants that do not require
forcedly purchsed trains to run (at least 1844). Actually, I started
with a 2-train route check only to leave this approach when thinking
of hex trains. The patch could easily be amended to revert back to
that logic. (But, as Stefan said, the first step would consist of
clarify this in a discussion.)

Regarding rails' layering:
It would be a valid design decision to keep route awareness out of the
game engine. But then every consumer of the game engine has to take
care of becoming route aware on himself. Currently, that's not a big
deal as there is only one consumer (the UI). But in the longer term,
there could also be other consumers (RemoteHuman, AI) and, then,
having put route awareness into the game engine would come in very
handy.

Regarding incompatibility with Rails 2.0 (@Stefan):
Which aspect of this patch is incompatible to rails 2.0? Which
adjustment would be necessary in order to avert this?

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Frederick:
below are my follow-up comments on your patch.
So my proposals are:
* Move main code from OperatingRound to RevenueAdapter. Use a NetworkTrain 
that runs for 2 majors and check if it runs for non-zero revenue.
* Instead of modifying the game engine, change the message in the UI at time 
of train buying depending on that result.
* Keep the modification until "Enforce" RevenueCalculation options are 
available.
Stefan

My main point is that your patch does not comply to the current level of 
enforcement defined by the GameOptions.

Currently RouteCalculation is set to "Suggest",  thus it does not enforce the 
calculated amount (e.g. it does not prevent entering a revenue exceeding it). 

Other Options (planned for future) are:

* "Enforce" - In that level the game engine strictly enforces the rules 
without suggesting anything. Here Rails would calculate the optimal revenue, 
however it would not display the amount, it would only raise an error if a 
player enters revenue exceeding the calculated amount. This allows competitive 
play which might suite sophisticated players.

* "Suggest & Enforce" - This combines suggest and enforce and is optimal for 
novice players.

Your implementation falls into the latter category, as it both strictly 
enforces and indicates in the UI (by enabling/disabling the DONE button) if 
the company has a route or not.

To keep your patch in synch with "Suggest" it should not change the behavior 
of the game engine, but simply have the UI tell the player if or if not 
his/her company has to buy a train or not, depending if the route algorithm 
has found a route or not.

From a technical point of view:
I already stated that I suggest to add something like boolean hasRoute() to 
the RevenueAdapter inside the algorithm package.

So the consumers/clients below interacts with the algorithm package, in that 
sense the game engine is a client of algorithm if it needs that bit of 
information. 

If the UI itself gets the information feeded indirectly via the game engine or 
directly from algorithm is not that important anymore. It even might depend on 
what it is used for. If it is more a hint mechanism ("suggest") directly, if 
("enforce") it is rule enforcement indirectly.



> Regarding rails' layering:
> It would be a valid design decision to keep route awareness out of the
> game engine. But then every consumer of the game engine has to take
> care of becoming route aware on himself. Currently, that's not a big
> deal as there is only one consumer (the UI). But in the longer term,
> there could also be other consumers (RemoteHuman, AI) and, then,
> having put route awareness into the game engine would come in very
> handy.
> 

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Quick answers first, see below.

On Monday, January 02, 2012 08:14:03 am Frederick Weld wrote:
> Regarding the definition of routes:
> Thanks for pointing out that there are variants that do not require
> forcedly purchsed trains to run (at least 1844). Actually, I started
> with a 2-train route check only to leave this approach when thinking
> of hex trains. The patch could easily be amended to revert back to
> that logic. (But, as Stefan said, the first step would consist of
> clarify this in a discussion.)

My current favorite for an implementation is to run a virtual 2-train
and check if it shows non-zero income => Company has a route. That will run 
fast, is easy to implement and very close to what players might usually 
expect. This method could/should be implemented inside the algorithm package. 

> 
> Regarding rails' layering:
> It would be a valid design decision to keep route awareness out of the
> game engine. But then every consumer of the game engine has to take
> care of becoming route aware on himself. Currently, that's not a big
> deal as there is only one consumer (the UI). But in the longer term,
> there could also be other consumers (RemoteHuman, AI) and, then,
> having put route awareness into the game engine would come in very
> handy.

More on this in a later e-mail.

> 
> Regarding incompatibility with Rails 2.0 (@Stefan):
> Which aspect of this patch is incompatible to rails 2.0? Which
> adjustment would be necessary in order to avert this?

The incompatibility is narrowly defined in the sense that the commit/patch 
cannot be merged automatically with the Rails 2.0 patch:
All patches that include a change GameManager or any of the Round classes  
cannot be merged automatically anymore. 

It does not mean that it incompatible in a broader sense, it is only that 
someone has to do the merge manually at some time in the future. And as you 
are already implement faster as I can currently comment on, it is unlikely 
that I will be able to that ;-)

> 
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Rails 2.0 OperationRound Status & other RoundClasses

[<Dr....@t-...>]

Hi Stefan, 

	since i am currently fiddling in 1880 with some of those Classes
(Stock-/Start-/OperatingRound) i would love to know when you expect to
have a useable Class for crosschecks/refactoring the needed additions
for 1880 in rails 2.0. 

	   >> 
 >> Regarding incompatibility with Rails 2.0 (@Stefan):
 >> Which aspect of this patch is incompatible to rails 2.0? Which
 >> adjustment would be necessary in order to avert this?
 >
 >The incompatibility is narrowly defined in the sense that the
commit/patch 
 >cannot be merged automatically with the Rails 2.0 patch:
 >All patches that include a change GameManager or any of the Round
classes  
 >cannot be merged automatically anymore. 
 >
 >It does not mean that it incompatible in a broader sense, it is only
that 
 >someone has to do the merge manually at some time in the future. And
as you 
 >are already implement faster as I can currently comment on, it is
unlikely 
 >that I will be able to that ;-)

 Btw, Happy new Year to ye all.  Regards Martin

Re: [Rails-devel] Rails 2.0 OperationRound Status & other RoundClasses

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

Hi Martin,
good question: However I cannot and will not commit any date for this. 
The nice thing about the project here is that you do not work with time 
pressure, the bad thing is that it does not have the same priority as those 
from real life which have a schedule assigned.

To give a current guess in the best case it can be 2 months time, but it could 
also take 4 months, before Rounds will be implemented and stabilized.

I have recently update the Rails 2.0 package and you will realize that I have 
no even really started on breaking up the Round classes, as I still focus on 
the State/Model classes, but I expect that to finish soon. This will require 
some more testing and working to get stabilized again. 

Then I will start working on breaking up and redesigning the Round classes, so 
this should start in maybe a month or so.

As the developer of 1870 I am waiting for this to happen for two years now ;-)

Stefan


On Monday, January 02, 2012 01:20:44 pm Dr....@t-... wrote:
> Hi Stefan,
> 
> 	since i am currently fiddling in 1880 with some of those Classes
> (Stock-/Start-/OperatingRound) i would love to know when you expect to
> have a useable Class for crosschecks/refactoring the needed additions
> for 1880 in rails 2.0.
> 
>  >> Regarding incompatibility with Rails 2.0 (@Stefan):
>  >> Which aspect of this patch is incompatible to rails 2.0? Which
>  >> adjustment would be necessary in order to avert this?
>  >
>  >The incompatibility is narrowly defined in the sense that the
> 
> commit/patch
> 
>  >cannot be merged automatically with the Rails 2.0 patch:
>  >All patches that include a change GameManager or any of the Round
> 
> classes
> 
>  >cannot be merged automatically anymore.
>  >
>  >It does not mean that it incompatible in a broader sense, it is only
> 
> that
> 
>  >someone has to do the merge manually at some time in the future. And
> 
> as you
> 
>  >are already implement faster as I can currently comment on, it is
> 
> unlikely
> 
>  >that I will be able to that ;-)
> 
>  Btw, Happy new Year to ye all.  Regards Martin

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> My current favorite for an implementation is to run a virtual 2-train and
check
> if it shows non-zero income => Company has a route. That will run fast, is
> easy to implement and very close to what players might usually expect.
This
> method could/should be implemented inside the algorithm package.

Please be aware that in some games a minimal route requires a different
train, such as the good trains in 18VA and 1837 (coal companies).
In these cases that doesn't pose a problem because trains are always (18VA)
or never (1837 CC) required, but other cases may be different.
That's why I'm not too happy with linking route existence to specific
trains.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Erik:
running a virtual 2-train for any game is essentially identical to 

> i) Check if there is a route that connects one home token of the company
> with another scoring node (which is a valid terminate for a train in this 
game).

which was the option you preferred.

However it avoids adding further route finding code (which would be 
essentially code duplication). Or do you have other ideas in mind?

Stefan


On Monday, January 02, 2012 01:31:52 pm Erik Vos wrote:
> > My current favorite for an implementation is to run a virtual 2-train and
> 
> check
> 
> > if it shows non-zero income => Company has a route. That will run fast,
> > is easy to implement and very close to what players might usually
> > expect.
> 
> This
> 
> > method could/should be implemented inside the algorithm package.
> 
> Please be aware that in some games a minimal route requires a different
> train, such as the good trains in 18VA and 1837 (coal companies).
> In these cases that doesn't pose a problem because trains are always (18VA)
> or never (1837 CC) required, but other cases may be different.
> That's why I'm not too happy with linking route existence to specific
> trains.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, January 02, 2012 7:26 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Enforcement of forced train
> purchases
> 
> Erik:
> running a virtual 2-train for any game is essentially identical to
> 
> > i) Check if there is a route that connects one home token of the
> > company with another scoring node (which is a valid terminate for a
> > train in this
> game).

No, my point is that these two conditions aren't identical in some cases.  
In 18VA, a 2-train would score $0 between Lynchburg and Roanoke (the route
is invalid), whereas a 1G-train would score at least $50.

"A train" is not the same as "a 2-train".

However, this is just a warning from my side, as I'm currently not aware of
any games where it really matters. 

Erik.


> which was the option you preferred.
> 
> However it avoids adding further route finding code (which would be
> essentially code duplication). Or do you have other ideas in mind?
> 
> Stefan
> 
> 
> On Monday, January 02, 2012 01:31:52 pm Erik Vos wrote:
> > > My current favorite for an implementation is to run a virtual
> > > 2-train and
> >
> > check
> >
> > > if it shows non-zero income => Company has a route. That will run
> > > fast, is easy to implement and very close to what players might
> > > usually expect.
> >
> > This
> >
> > > method could/should be implemented inside the algorithm package.
> >
> > Please be aware that in some games a minimal route requires a
> > different train, such as the good trains in 18VA and 1837 (coal
companies).
> > In these cases that doesn't pose a problem because trains are always
> > (18VA) or never (1837 CC) required, but other cases may be different.
> > That's why I'm not too happy with linking route existence to specific
> > trains.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -----
> > --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> > complex infrastructure or vast IT resources to deliver seamless,
> > secure access to virtual desktops. With this all-in-one solution,
> > easily deploy virtual desktops for less than the cost of PCs and save
> > 60% on VDI infrastructure costs. Try it free!
> > http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
desktops
> for less than the cost of PCs and save 60% on VDI infrastructure costs.
Try it
> free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Regarding "a train":
One option to accomodate both Erik's and Stefan's approach would be as
follows: Each 18xx variant has a set of trains that are relevant for
checking routes. For performance reasons, this set should be minimal.
So for 1830 it would be {2} and for 18VA (if it had route-dependent
enforcement) would be {2,1G}. The adapter's route check would be run
with this set.

Regarding "each consumer directly accesses the algorithm package":
Functionally, Stefan has made a valid point. But having performance in
mind, it might be better if network information would not always be
built from the scratch for each kind of check in every consumer. For
example, in SimTex's 1830, network information (both used for UI/AI)
is built/updated after each action. The needed component
("NetworkState") would reside below the game engine consumers and
either be part of the game engine or be placed on top of it. But
perhaps such design is only the target in the longer term.

Regarding "suggest vs. enforce":
Thanks to Stefan for pointing out this pitfall. Actually I had
envisaged "enforce" (not "suggest") during development. Would it be
acceptable to introduce the new mode "suggest & enforce" if only some
aspects are enforced (train purchase) and others not? I ask that
because the gain of applying the forced train purchase logic for
displaying a different info message would be not too big (in my
opinion).

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

See comments below

On Tuesday, January 03, 2012 08:27:16 am Frederick Weld wrote:
> Regarding "a train":
> One option to accomodate both Erik's and Stefan's approach would be as
> follows: Each 18xx variant has a set of trains that are relevant for
> checking routes. For performance reasons, this set should be minimal.
> So for 1830 it would be {2} and for 18VA (if it had route-dependent
> enforcement) would be {2,1G}. The adapter's route check would be run
> with this set.

That is possible, however I do not recommend to implement features potentially
never used. From my experience after some time they get untested and/or 
unmaintained. For the time being I would define a static global inside 
RevenueAdapter.

And I doubt that you have to worry about the performance, if you run each 
train separately (this was the minor "bug" in your implementation: It you want 
to test many trains, it is much faster to run each once). And you could even 
stop after the first intermediate update that a solution is found, as you do 
not care for the optimal solution.

> 
> Regarding "each consumer directly accesses the algorithm package":
> Functionally, Stefan has made a valid point. But having performance in
> mind, it might be better if network information would not always be
> built from the scratch for each kind of check in every consumer. For
> example, in SimTex's 1830, network information (both used for UI/AI)
> is built/updated after each action. The needed component
> ("NetworkState") would reside below the game engine consumers and
> either be part of the game engine or be placed on top of it. But
> perhaps such design is only the target in the longer term.

I thought about that (Alex suggested it as well some time ago): However I see 
many more advantages keeping algorithm stateless. All state information is 
stored inside the Rails game engine. Consider the algorithm defining an 
appropriate view on the Rails database first and throwing away the data after 
each use.

And think about the consequences: 
* Everything you want to store have to be Rails state variables (to allow 
undo). 
* You have to define triggers from all actions that might change the network.
* There are lot of optimization that still have to be run each time again.
* Most likely you will have to keep a network per company.
* Debugging will be horrible in those cases where the Rails engine state and 
the Network state gets out of synch.
* And the performance gain is minimal, as the time needed for route 
calculation by far exceeds the required time of creating the network.

> 
> Regarding "suggest vs. enforce":
> Thanks to Stefan for pointing out this pitfall. Actually I had
> envisaged "enforce" (not "suggest") during development. Would it be
> acceptable to introduce the new mode "suggest & enforce" if only some
> aspects are enforced (train purchase) and others not? I ask that
> because the gain of applying the forced train purchase logic for
> displaying a different info message would be not too big (in my
> opinion).

From my point of view I would not add this to Rails 1.x, but in the end this 
is up to you.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, January 03, 2012 12:12 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Enforcement of forced train
> purchases
> 
> See comments below
> 
> On Tuesday, January 03, 2012 08:27:16 am Frederick Weld wrote:
> > Regarding "a train":
> > One option to accomodate both Erik's and Stefan's approach would be as
> > follows: Each 18xx variant has a set of trains that are relevant for
> > checking routes. For performance reasons, this set should be minimal.
> > So for 1830 it would be {2} and for 18VA (if it had route-dependent
> > enforcement) would be {2,1G}. The adapter's route check would be run
> > with this set.
> 
> That is possible, however I do not recommend to implement features
> potentially never used. From my experience after some time they get
> untested and/or unmaintained. For the time being I would define a static
> global inside RevenueAdapter.

I suppose you mean: define and use a fixed set {2}, and I agree with that
idea. 
At least we would then have a placeholder that we could later make
configurable, should the need arise.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Another related aspect is as follows:

Currently, parts of the game engine (OperatingRound and
action.BuyTrain) are conceived in such a way that they need to know
whether the company is forced to buy a train (since only then the
president is allowed to add his cash).
If the game engine was held unaware of routes, it would also be unable
to determine the possible actions of buy train.

What would be the design to cope with this situation?

Should the game engine consumer filter out all those actions that
necessite president cash for BuyTrain, in case the train purchase was
not forced?

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Frederick:
as long as Rails only support a "Suggest" option for routes, the communication 
and mechanisms between the UI and the game engine could and should be kept 
unchanged. The UI would present the most likely correct default, however the 
user can still decided to deviate.

I have not implemented that part of Rails, thus Erik could possibly add more 
how the user decision feeds back to the game engine. But if I remember 
correctly the user is simply always able to add own cash currently. Like for a 
real ftf game the user has to refrain from such an illegal action.

Only for an "Enforce" option this question is relevant for the game engine, as 
for the all other use cases.

Stefan


On Tuesday, January 03, 2012 02:40:19 pm Frederick Weld wrote:
> Another related aspect is as follows:
> 
> Currently, parts of the game engine (OperatingRound and
> action.BuyTrain) are conceived in such a way that they need to know
> whether the company is forced to buy a train (since only then the
> president is allowed to add his cash).
> If the game engine was held unaware of routes, it would also be unable
> to determine the possible actions of buy train.
> 
> What would be the design to cope with this situation?
> 
> Should the game engine consumer filter out all those actions that
> necessite president cash for BuyTrain, in case the train purchase was
> not forced?
> 
> ---------------------------------------------------------------------------
> --- Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Currently (origin/master), the game engine enforces that the president
may only add cash if he has no train and his company is tagged with
<train... mandatory="yes"> (which represents a necessary condition for
forced train purchases).

Given your answer, the goal would be to omit this enforcement.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> as long as Rails only support a "Suggest" option for routes, the
> communication and mechanisms between the UI and the game engine could
> and should be kept unchanged. The UI would present the most likely correct
> default, however the user can still decided to deviate.
> 
> I have not implemented that part of Rails, thus Erik could possibly add
more
> how the user decision feeds back to the game engine. 

Always via PossibleAction object, in this case SetDividend, which also
includes the chosen (or predefined) revenue allocation: withhold, split or
payout.

Obviously, with "Enforce" the game engine could/should validate and possibly
reject the revenue amount. 

Erik.