rails-devel

[Rails-devel] 1880 Implementation: Opinions wanted

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

Hi, 

	i would like to get some opinions for two todos next on my list. 

	a) Major Companies in 1880 have their tile laying rights bound to a
"building" right. This will be determined not at creation of that
company but at Start based on the director share type and the player
chosing from a number of indefinetely available rights. 

	In Connect with that "semi-static" Right, the company in question
will receive a numer of rights if the director of that company holds a
private (Taiwan, Ferry, Bridge). Its not linked to the company but
through the player to all companies he owns. 

	If i want to display those right i think i'll have to make use of the
not yet fully implemented RightsModel Class. Any objections, different
approach suggestions here ?

	b) the train lending feature: For the Investors/Minor Companies the
currently in the bank available train is used to determine the
Revenue. 

	I would like to have that displayed in the companies portfolio and of
course used in the revenue calculation. 

	I propose to generate a 4th heap/portfolio which will hold the not
yet leased/lent trains and then use a leaseTrain method that will move
those trains into the Minors portfolio upon start/event and move the
already listed trains to the scrap heap. 

	Any ideas there ? Cause the low level approch of using the Portfolio
mechanismn directly is not what should be done or? (Besides we dont
have a removeTrain method thats visible outside of Portfolio for a
reason anyway.) 

	Regards, 

	Martin

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

My initial views:

 

a)       

Currently, there are two ways to assign rights to Players and to Companies: with SpecialProperties and with Rights.

SpecialProperties always (at least so far) come with acquired private companies.  In a game like 1835, the special property immediately transfers to the player owning the private, and I believe this is the way you should try to implement the 1880 private properties as well.  Implementing new special properties is not trivial, and I think that in many cases you will have to create new (either generic or 1880-specific) SpecialProperty subclasses.  Of course I’ll be willing to help you out.

 

I understand you would like to display such player-owned private rights in the UI.  This is not yet done anywhere.  A Rails principle is that players ought to know the game rules, and in this case, what special rights they have when owning certain privates (which *are* displayed). They can also look up private rights in the Info menu.  See 1830 for examples.

 

Right has been created for 1830 Coalfields and is  intended to take care of properties that are not linked to privates but can be acquired by everyone.  I have considered handling the Coalfields right as a SpecialProperty as well, but handling was too different to make that achievable without major changes.  I would think that the 1880 building rights should be implemented as Rights, but (as always) the proof of the pudding will be in the eating. 

 

As with all new generic items intended to cover new game-specific features that *may* have general impact, I consider the Rights implementation as provisional as long as it has not been proven to be able to cover multiple cases, and Rights definitely falls into this class.

 

a)       

I believe this is the same situation as we have with 1856 if the CGR has no train: it “borrows” the train that currently is on top of the IPO stack.  Effectively, it runs that train without ever getting it.  I think the same solution should apply to 1880.  So we don’t need a new portfolio: it already exists, and is called “IPO”.

 

As for displaying a borrowed train: if that doesn’t already happen in 1856, it’s probably a good idea to add it there too, so it would be a generic feature.  I would start checking out if updating TrainsModel could cover such a case, e.g. by adding a method ‘useBorrowedTrain (Portfolio ipo)’.  Passing a reference to IPO would cause displaying the first available IPO train in square brackets (for instance).  Passing null would switch that off and return to the normal display.

 

Erik.

 

 

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Sunday, January 29, 2012 12:22 AM
To: Rails Development
Subject: [Rails-devel] 1880 Implementation: Opinions wanted

 

Hi,

 

i would like to get some opinions for two todos next on my list.

 

a) Major Companies in 1880 have their tile laying rights bound to a "building" right. This will be determined not at creation of that company but at Start based on the director share type and the player chosing from a number of indefinetely available rights.

 

In Connect with that "semi-static" Right, the company in question will receive a numer of rights if the director of that company holds a private (Taiwan, Ferry, Bridge). Its not linked to the company but through the player to all companies he owns.

 

If i want to display those right i think i'll have to make use of the not yet fully implemented RightsModel Class. Any objections, different approach suggestions here ?

 

b) the train lending feature: For the Investors/Minor Companies the currently in the bank available train is used to determine the Revenue.

I would like to have that displayed in the companies portfolio and of course used in the revenue calculation.

 

I propose to generate a 4th heap/portfolio which will hold the not yet leased/lent trains and then use a leaseTrain method that will move those trains into the Minors portfolio upon start/event and move the already listed trains to the scrap heap.

 

Any ideas there ? Cause the low level approch of using the Portfolio mechanismn directly is not what should be done or? (Besides we dont have a removeTrain method thats visible outside of Portfolio for a reason anyway.)

 

Regards,

Martin

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Martin & Erik:
I will only comment on the second item:

The train lending feature of 1856 is implemented by having
the PublicCompany_CGR extending a StaticRevenueModifier.
Most likely a similar solution should work for 1880 as well.

Stefan

More details:

This interface requires only one method to implement, see below the 
implementation for 1856.

     public boolean modifyCalculator(RevenueAdapter revenueAdapter) {
         // check if the running company is the cgr
         if (revenueAdapter.getCompany() != this) return false;

         // add the diesel train
         if (runsWithBorrowedTrain()) {
             revenueAdapter.addTrainByString("D");
             return true;
         }
         return false;
     }

Some remarks:

* Static modifiers is called for all companies (so the modifier has to 
check if it the running company is actually the CGR).

* The train used for revenue calculation is actually a "virtual" train, 
which is only created for the use of revenue calculation.





> b)
>
> I believe this is the same situation as we have with 1856 if the CGR has
> no train: it “borrows” the train that currently is on top of the IPO
> stack.  Effectively, it runs that train without ever getting it.  I
> think the same solution should apply to 1880.  So we don’t need a new
> portfolio: it already exists, and is called “IPO”.
>
> As for displaying a borrowed train: if that doesn’t already happen in
> 1856, it’s probably a good idea to add it there too, so it would be a
> generic feature.  I would start checking out if updating TrainsModel
> could cover such a case, e.g. by adding a method ‘useBorrowedTrain
> (Portfolio ipo)’.  Passing a reference to IPO would cause displaying the
> first available IPO train in square brackets (for instance).  Passing
> null would switch that off and return to the normal display.
>
> Erik.
>
> *From:*Dr....@t-... [mailto:Dr....@t-...]
> *Sent:* Sunday, January 29, 2012 12:22 AM
> *To:* Rails Development
> *Subject:* [Rails-devel] 1880 Implementation: Opinions wanted
>
> Hi,
>
> i would like to get some opinions for two todos next on my list.
>
> a) Major Companies in 1880 have their tile laying rights bound to a
> "building" right. This will be determined not at creation of that
> company but at Start based on the director share type and the player
> chosing from a number of indefinetely available rights.
>
> In Connect with that "semi-static" Right, the company in question will
> receive a numer of rights if the director of that company holds a
> private (Taiwan, Ferry, Bridge). Its not linked to the company but
> through the player to all companies he owns.
>
> If i want to display those right i think i'll have to make use of the
> not yet fully implemented RightsModel Class. Any objections, different
> approach suggestions here ?
>
> b) the train lending feature: For the Investors/Minor Companies the
> currently in the bank available train is used to determine the Revenue.
>
> I would like to have that displayed in the companies portfolio and of
> course used in the revenue calculation.
>
> I propose to generate a 4th heap/portfolio which will hold the not yet
> leased/lent trains and then use a leaseTrain method that will move those
> trains into the Minors portfolio upon start/event and move the already
> listed trains to the scrap heap.
>
> Any ideas there ? Cause the low level approch of using the Portfolio
> mechanismn directly is not what should be done or? (Besides we dont have
> a removeTrain method thats visible outside of Portfolio for a reason
> anyway.)
>
> Regards,
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

OK, so using the borrowed train is covered, and Martin could try to copy the
CGR functionality. 

Displaying that borrowed train (e.g. like '[D]') is a different matter, and
if anyone thinks it's important I'm willing to have a look into that issue.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, January 29, 2012 7:20 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1880 Implementation: Opinions wanted
> 
> Martin & Erik:
> I will only comment on the second item:
> 
> The train lending feature of 1856 is implemented by having the
> PublicCompany_CGR extending a StaticRevenueModifier.
> Most likely a similar solution should work for 1880 as well.
> 
> Stefan
> 
> More details:
> 
> This interface requires only one method to implement, see below the
> implementation for 1856.
> 
>      public boolean modifyCalculator(RevenueAdapter revenueAdapter) {
>          // check if the running company is the cgr
>          if (revenueAdapter.getCompany() != this) return false;
> 
>          // add the diesel train
>          if (runsWithBorrowedTrain()) {
>              revenueAdapter.addTrainByString("D");
>              return true;
>          }
>          return false;
>      }
> 
> Some remarks:
> 
> * Static modifiers is called for all companies (so the modifier has to
check if it
> the running company is actually the CGR).
> 
> * The train used for revenue calculation is actually a "virtual" train,
which is
> only created for the use of revenue calculation.
> 
> 
> 
> 
> 
> > b)
> >
> > I believe this is the same situation as we have with 1856 if the CGR has
> > no train: it "borrows" the train that currently is on top of the IPO
> > stack.  Effectively, it runs that train without ever getting it.  I
> > think the same solution should apply to 1880.  So we don't need a new
> > portfolio: it already exists, and is called "IPO".
> >
> > As for displaying a borrowed train: if that doesn't already happen in
> > 1856, it's probably a good idea to add it there too, so it would be a
> > generic feature.  I would start checking out if updating TrainsModel
> > could cover such a case, e.g. by adding a method 'useBorrowedTrain
> > (Portfolio ipo)'.  Passing a reference to IPO would cause displaying the
> > first available IPO train in square brackets (for instance).  Passing
> > null would switch that off and return to the normal display.
> >
> > Erik.
> >
> > *From:*Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > *Sent:* Sunday, January 29, 2012 12:22 AM
> > *To:* Rails Development
> > *Subject:* [Rails-devel] 1880 Implementation: Opinions wanted
> >
> > Hi,
> >
> > i would like to get some opinions for two todos next on my list.
> >
> > a) Major Companies in 1880 have their tile laying rights bound to a
> > "building" right. This will be determined not at creation of that
> > company but at Start based on the director share type and the player
> > chosing from a number of indefinetely available rights.
> >
> > In Connect with that "semi-static" Right, the company in question will
> > receive a numer of rights if the director of that company holds a
> > private (Taiwan, Ferry, Bridge). Its not linked to the company but
> > through the player to all companies he owns.
> >
> > If i want to display those right i think i'll have to make use of the
> > not yet fully implemented RightsModel Class. Any objections, different
> > approach suggestions here ?
> >
> > b) the train lending feature: For the Investors/Minor Companies the
> > currently in the bank available train is used to determine the Revenue.
> >
> > I would like to have that displayed in the companies portfolio and of
> > course used in the revenue calculation.
> >
> > I propose to generate a 4th heap/portfolio which will hold the not yet
> > leased/lent trains and then use a leaseTrain method that will move those
> > trains into the Minors portfolio upon start/event and move the already
> > listed trains to the scrap heap.
> >
> > Any ideas there ? Cause the low level approch of using the Portfolio
> > mechanismn directly is not what should be done or? (Besides we dont have
> > a removeTrain method thats visible outside of Portfolio for a reason
> > anyway.)
> >
> > Regards,
> >
> > Martin
> >
> >
> >
> >
----------------------------------------------------------------------------
--
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> >
> >
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

@Martin & Erik:
When reading this thread, I'm wondering how you will merge all these
changes to the game engine into 2.0.
Perhaps I'm missing some important information here, but as far as I
know, all changes to game engine will be dropped when migrating to
2.0.

@Stefan:
Wouldn't it make sense if master was merged right now into 2.0 and,
from that point in time on, everyone who changes master is responsible
for also keeping 2.0 up-to-date? (still keeping two separate branches,
of course, for retaining a working version )
That would have the benefit that everyone can directly perceive
whether his changes will be valid in 2.0 (and, if not, how to adjust).
If only merging once 2.0 is ready, we will have to deal with
incompatible commits that were performed several months ago the
content/interdependencies of which have long been forgotten...
At least for me, I would prefer double-maintenance now to that
situation in the near future.

--Frederick

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Hi Frederik, 

	honestly i would prefer them to be moved to 2.0. But shall i wait
till Stefan has finished 2.0 so that one can implement and test
everything on 2.0 ? 

	Thats lost time (and more time imho then it should need to adapt
everything to 2.0). 

	Regarding your implementations, can you be sure that those work in
2.0 yet ? 

	So i think we will have to live with the split here and wait for
Stefan to bring 2.0 to a working condition. 

	Regards,
Martin

	  Von: Frederick Weld <fre...@go...>
 An: "Development list for Rails: an 18xx game"
<rai...@li...>
 Betreff: Re: [Rails-devel] 1880 Implementation: Opinions wanted
 Datum: Sun, 29 Jan 2012 17:12:56 +0100

 @Martin & Erik:
 When reading this thread, I'm wondering how you will merge all these
 changes to the game engine into 2.0.
 Perhaps I'm missing some important information here, but as far as I
 know, all changes to game engine will be dropped when migrating to
 2.0.

 @Stefan:
 Wouldn't it make sense if master was merged right now into 2.0 and,
 from that point in time on, everyone who changes master is
responsible
 for also keeping 2.0 up-to-date? (still keeping two separate
branches,
 of course, for retaining a working version )
 That would have the benefit that everyone can directly perceive
 whether his changes will be valid in 2.0 (and, if not, how to
adjust).
 If only merging once 2.0 is ready, we will have to deal with
 incompatible commits that were performed several months ago the
 content/interdependencies of which have long been forgotten...
 At least for me, I would prefer double-maintenance now to that
 situation in the near future.

 --Frederick

 ------------------------------------------------------------------------------
 Try before you buy = See our experts in action!
 The most comprehensive online learning library for Microsoft
developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-dev2
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Martin:
> Regarding your implementations, can you be sure that those work in 2.0 yet ?

The probability of merge issues is very low as I have restricted all
my implementations on the UI / Sound layer (the exceptions to this
have been reverted yesterday).
But you're right that, even if my commits pass the merge hurdle,
functionality is a completely different story.

-- Frederick

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Sunday, January 29, 2012 5:13 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1880 Implementation: Opinions wanted
> 
> @Martin & Erik:
> When reading this thread, I'm wondering how you will merge all these
> changes to the game engine into 2.0.
> Perhaps I'm missing some important information here, but as far as I know,
> all changes to game engine will be dropped when migrating to 2.0.

>From my POV, that's up to Stefan.  My current position is, that I'm only
feeling responsible for 1.x.  If and when that will change, I can't say
right now.

Erik.
 
> @Stefan:
> Wouldn't it make sense if master was merged right now into 2.0 and, from
> that point in time on, everyone who changes master is responsible for also
> keeping 2.0 up-to-date? (still keeping two separate branches, of course,
for
> retaining a working version ) That would have the benefit that everyone
can
> directly perceive whether his changes will be valid in 2.0 (and, if not,
how to
> adjust).
> If only merging once 2.0 is ready, we will have to deal with incompatible
> commits that were performed several months ago the
> content/interdependencies of which have long been forgotten...
> At least for me, I would prefer double-maintenance now to that situation
in
> the near future.
> 
> --Frederick
> 
>
----------------------------------------------------------------------------
--
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Martin, Erik & Frederick:
this is a summary answer to the discussion that arose after this mail:

 From the beginning I clearly stated that it is my intention to make 
some changes to the internal working of Rails, especially to the state 
and model packages and then moving up to the round classes.

Master and Rails2.0 started to deviate after release 1.5 and I have
no intention to merge all commits after that now:

The main obstacle to merge things now is that there is no way to decide 
if they are functionally correct, as the Rails 2.0 does not even compile 
now. So I would not recommend anyone to merge at this point in time.

If the 1.x merges get merged and by whom later on is open: Simple bug 
fixes most likely can be merged easily, your stuff should be mergeable 
after a few changes, however other things will be more difficult, but 
not impossible.

Most likely Martin's argument is correct: Why waste the time to wait for 
Rails2.0 to start developing, if one has spare time to do so now.
In the worst case one can use the experience from that to add an even 
better implementation to Rails2.0 at the time the development of 2.0 
allows to do so.

So my main point is to keep the issue transparent to avoid 
disappointment later but I do not actively discouraging all of you who 
are keen to add new features which work immediately.
However I currently prefer to improve the base layer where everything 
can be built upon.

Stefan



On 01/29/2012 05:12 PM, Frederick Weld wrote:
> @Martin&  Erik:
> When reading this thread, I'm wondering how you will merge all these
> changes to the game engine into 2.0.
> Perhaps I'm missing some important information here, but as far as I
> know, all changes to game engine will be dropped when migrating to
> 2.0.
>
> @Stefan:
> Wouldn't it make sense if master was merged right now into 2.0 and,
> from that point in time on, everyone who changes master is responsible
> for also keeping 2.0 up-to-date? (still keeping two separate branches,
> of course, for retaining a working version )
> That would have the benefit that everyone can directly perceive
> whether his changes will be valid in 2.0 (and, if not, how to adjust).
> If only merging once 2.0 is ready, we will have to deal with
> incompatible commits that were performed several months ago the
> content/interdependencies of which have long been forgotten...
> At least for me, I would prefer double-maintenance now to that
> situation in the near future.
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel