Menu
▾
▴
Re: [Rails-devel] Coalfields and states
|
From: Stefan F. <ste...@we...> - 2011-07-07 05:50:45
|
I have added the revenue support for the Coalfield rights.
This and the commit before should complete the support of Reading and
Coalfield variants, am I right?
Several issues arose:
A) Reading the rules carefully it seems that the rights are only required for
the revenue train run, not for tracing a route for tile and token laying. Do
all agree on this?
SpecialRights accordingly implements the RevenueStaticModifier.
B) Suprisingly (to me at least) SpecialRights has to no location field, thus I
had to hardcode the coalfield hex location. On the other hand I did not know
what to do with fields rightValue and rightDefaultValue.
C) The finishConfiguration method of SpecialProperties for a (Public)Company
were not called. I added the missing call to the finishConfiguration of
PublicCompany. I have not checked if this call is also missing for
PrivateCompany and/or should be better moved up to the Company class.
D) Personally I am not too happy that the main code parts of Rights (which in
my view is not a very general part of 18xx) are inside the main classes
PublicCompany and OperatingRound, which are already difficult to understand
and in my view have grown too large. But breaking up the Round classes has
been on my agenda for long and I know that Erik is not happy about that idea
neither ;-)
Stefan
On Friday, July 01, 2011 01:02:40 am Erik Vos wrote:
> Actually, I'm just now running into a problem related to Stefan's thoughts
> about states.
>
> Today I have committed the changes needed to enable buying the 1830
> Coalfield access allowance. It's implemented completely generically via a
> new concept called Rights, owned by companies. A Right can be bought via a
> new SpecialRight special property, which can be configured in
> CompanyManager.xml. A Right has a name and a value, both strings. For
> Coalfields, we don't need the value, which is just null. But I thought
> values might prove useful one day. A company's rights are stored in a
> HashMapState.
>
> For Stefan: to know whether or not a company has the Coalfields right, call
> the PublicCompany hasRight("Coalfields") method. I suppose you pick it up
> from here.
>
> I have added new 'Rights' columns to the GameStatus and OR windows. These
> columns only show up if applicable in a game - only Coalfields, so far. If
> a company buys the 'Coalfields' right, that name shows up in the Rights
> column for that company.
>
> And there is the catch: because Stefan's HashMapState does not extend State
> (or at least ModelObject), Undo cannot remove the 'Coalfields' display,
> and I know of no other way to accomplish that. I'll leave it in this
> state, until it's clear where we will be heading with the state package.
>
> To accomplish adding these rights, I had to do some refactoring of company
> initialization. Formerly, for each type a dummy company was created, to
> hold the defaults defined in <CompanyType>. These dummy companies were
> then cloned into real companies, but the cloning is shallow and was not
> for the first time getting me into problems. I'm now reparsing the
> <CompanyType> inner XML repeatedly for each <Company> to set the defaults
> before parsing the specific company XML. Recently I have done a very
> similar change on train creation, and I think it's much cleaner this way.
> This refactoring caused some bad side effects, but that turned out to be
> an initialization sequence problem. Nevertheless, please look out for
> problems, in particular when processing saved files.
>
> Erik.
>
> > -----Oorspronkelijk bericht-----
> > Van: brett lentz [mailto:bre...@gm...]
> > Verzonden: donderdag 30 juni 2011 17:32
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Subphases
> >
> > I think your way is completely adequate and fine (for now).
> >
> > The main reason I bring up a Triggerable concept is because it will
> > integrate more easily with Runnable and friends, which are required for
> > client/server communications. We'll need the server-side thread watching
> > for events coming from the client-side. Triggered events are one of many
> > that we'd need to watch for.
> >
> > ---Brett.
> >
> > On Thu, Jun 30, 2011 at 2:37 AM, Erik Vos <eri...@xs...> wrote:
> > > I also remember that Stefan and I didn't agree on the usefulness of his
> >
> > approach, although the details have escaped me.
> >
> > > Personally, I feel that we have all we need. All State classes already
> >
> > implement Observable, mainly to update the GUI, but I think I'm also
> > using Observers in a few cases inside the game engine. But to trigger
> > actions I usually prefer simple method calls to stubs that can be
> > overridden, because that way it's easier for me to follow the program
> > flow, during programming and in particular when debugging.
> >
> > > On the other hand, I must admit that the two of you are probably much
> >
> > better versed in 'state-of-the-art' Java program design than I am, so I'm
> > prepared to rest my case(s) - but I can't promise that I will not
> > continue doing things my way. Unless you manage to convince me.
> >
> > > Erik.
> > >
> > >> -----Oorspronkelijk bericht-----
> > >> Van: Stefan Frey [mailto:ste...@we...]
> > >> Verzonden: donderdag 30 juni 2011 8:38
> > >> Aan: Development list for Rails: an 18xx game
> > >> Onderwerp: Re: [Rails-devel] Subphases
> > >>
> > >> Following a similar discussion last year I started a refactoring of
> > >> the State classes which includes such a generic trigger approach. It
> > >> allows a delayed initialization, separation of trigger and
> > >> triggerable and definition of generalized triggers. I will give more
> > >> details of that next week when I have access to my Pc. However it
> > >> does not solve the more specific issues around
> > >> (sub) phases. Stefan
> > >>
> > >> brett lentz <bre...@gm...> schrieb:
> > >> >What about creating a generic Triggerable interface that defines a
> > >> >small handful of methods for causing something to happen? Any class
> > >> >could then implement this interface to register an event that
> > >> >doesn't follow the normal game sequencing.
> > >> >
> > >> >If GameManager (or another appropriate controller) has a mechanism
> > >> >for registering all Triggerable events, and then during each action
> > >> >or phase change that list of registered Triggerables is consulted
> > >> >for firing off any relevant non-standard actions.
> > >> >
> > >> >---Brett.
> > >> >
> > >> >On Wed, Jun 29, 2011 at 2:07 AM, Erik Vos <eri...@xs...> wrote:
> > >> >> Thanks for the reminders.
> > >> >>
> > >> >> In particular rereading the 1837 rules has made it clear to me
> > >> >> that my concepts need refinement (I don't own 1853).
> > >> >>
> > >> >> 1. 1837 has two separate but interrelated train upgrade sequences:
> > >> >> [2, 3,
> > >> >> 3+1, 4, 4E, 4+1, 4+2, 5, 5E, 5+2, 5+3, 5+4] and [1G, 2G, 3G, 4G].
> > >> >> 2. 1837 has three "official" phases [1, 2, 3], but a total 8
> > >> >> (sub)phases in my new sense of the word [2, 3, 3+1, 4, 4E, 4+1, 5,
> > >> >> 5+2], and here phase naming becomes a problem. Perhaps something
> > >> >> 5+like
> > >>
> > >> "1[2]", "2[4E]", "3[5+2]"?
> > >>
> > >> >> With game-specific complexities there always is a trade-off
> > >> >> between implementing these as generic (configurable) or specific
> > >> >> (hardcoded) processes. The number of games in which a certain
> > >> >> feature shows up is just one factor; others include compatibility
> > >> >> with existing code, size of code, and simply just what is easier
> > >> >> to do. Quite a number of options used in only one game have been
> > >> >> implemented in a generic way, just because it was very simple. We
> > >> >> haven't done enough games yet to comment on the reverse
> > >> >> possibility, but we will have to look at that once we are getting
> > >> >> to implement more than one member of families like
> > >> >> 1835/1837/1876-35,
> > >> >> 1825/1853/1860 (if I'm right about 1860), etc. In any case, all
> > >> >> of the 1830 base game is generic.
> > >> >>
> > >> >> The 1837 peculiarities will most likely be implemented in special
> > >> >> code, but you have made it perfectly clear that my automatic train
> > >> >> progression idea needs modification, or at least a hook so that it
> > >> >> can be overridden in special code.
> > >> >>
> > >> >> Erik.
> > >> >>
> > >> >>> -----Oorspronkelijk bericht-----
> > >> >>> Van: John David Galt [mailto:jd...@di...]
> > >> >>> Verzonden: woensdag 29 juni 2011 0:12
> > >> >>> Aan: Development list for Rails: an 18xx game
> > >> >>> Onderwerp: Re: [Rails-devel] Subphases
> > >> >>>
> > >> >>> On 2011-06-28 02:44, Erik Vos wrote:
> > >> >>> > I vaguely remember that a few other games also have such
> > >> >>> > 'subphases' - does anyone have an overview?
> > >> >>>
> > >> >>> The most involved set of phases I've seen is 1837. 2038 also
> > >> >>> goes into a
> > >> >>
> > >> >> lot of
> > >> >>
> > >> >>> complications, though I don't expect to see it supported soon
> >
> > anyway.
> >
> > >> >>> > In the new Phase concept, a phase can be triggered by buying
> > >> >>> > any (not just the first) train of a type, and define up to
> > >> >>> > three different kinds
> > >> >>
> > >> >> of
> > >> >>
> > >> >>> entity:
> > >> >>> > 1. New values for standard properties, such as which tile
> > >> >>> > colours
> > >> >>
> > >> >> can
> > >> >>
> > >> >>> > be laid, is buying privates allowed, which off-board values
> > >> >>> > apply, etc. All properties propagate from one phase to the
> > >> >>> > next, unless
> > >> >>
> > >> >> changed
> > >> >>
> > >> >>> explicitly.
> > >> >>>
> > >> >>> > Nothing new here, this is already in place.
> > >> >>>
> > >> >>> Some others that deserve mention: which set of rules apply to
> > >> >>> financing of major companies started in this phase (1856, 18EU);
> > >> >>> which map areas are
> > >> >>
> > >> >> off
> > >> >>
> > >> >>> limits for running (1835) and/or building (1837); whether loans
> > >> >>> are
> > >> >>
> > >> >> available.
> > >> >>
> > >> >>> In the case of new train limits I would declare the new limit
> > >> >>> here, but
> > >> >>
> > >> >> make
> > >> >>
> > >> >>> enforcing it (discarding the trains) a separate action of type 2
> > >> >>> or 3,
> > >> >>
> > >> >> since the
> > >> >>
> > >> >>> timing varies by game. (1835 requires each minor to discard
> > >> >>> excess trains before Pr formation can begin, but 1856 and 18MEX
> > >> >>> allow CGR/NdM to wait and see which companies are going to merge
> > >> >>> into
> > >>
> > >> them
> > >>
> > >> >>> before deciding which trains to keep.)
> > >> >>>
> > >> >>> > 2. Actions to be executed immediately, such as rusting or
> > >> >>
> > >> >> obsoleting
> > >> >>
> > >> >>> > trains, making new trains available[1], closing privates. Only
> > >> >>> > the
> > >> >>> > private- closing action already exists. The train-related
> > >> >>> > actions are currently defined with the train types, and the
> > >> >>> > idea is to move these to the phase definitions, if for
> > >> >>> > consistency
> >
> > only.
> >
> > >> >>> Agree, and let's add some more: removing tiles and tokens from
> > >> >>> newly
> > >> >>> off- limits map areas (1837); making automatic tile placements
> > >> >>> (also 1837, but
> > >> >>
> > >> >> this
> > >> >>
> > >> >>> is how I would implement changes to red-area payouts and
> > >> >>> similar);
> > >> >>>
> > >> >>> > 3. Actions to be executed later, by setting a temporary
> > >> >>> > condition. This would apply to the 18TN Civil War, and perhaps
> > >> >>> > also to already existing delayed actions like the 18EU Final
> > >> >>> > Minor Exchange Round, and the 1835 Prussian formation
> > >> >>> > (triggering of these actions is now specially hardcoded). The
> > >> >>> > Phase class would only need a generic mechanism to set such
> > >> >>> > conditions (probably just strings), the detection, execution,
> > >> >>> > and
> > >> >>> > resetting will always be in game-specific
> > >> >>
> > >> >> code.
> > >> >>
> > >> >>> I agree with all but the last clause. Some of these actions are
> > >> >>> the same
> > >> >>
> > >> >> in
> > >> >>
> > >> >>> multiple games and should be shared code. For instance, in 1837,
> > >> >>
> > >> >> formation
> > >> >>
> > >> >>> of the KK and Ug uses optional trade-ins at the beginning of each
> > >> >>> round
> > >> >>
> > >> >> that
> > >> >>
> > >> >>> are almost identical to 1835's Pr.
> > >> >>>
> > >> >>> > [1] Making the next train type available after buying the last
> > >> >>> > train of a type would remain automatic. It would be silly to
> > >> >>> > start defining subphases for that purpose.
> > >> >>>
> > >> >>> Here I disagree. Take 1853. Yes, the last 2 train makes 3
> > >> >>> trains
> > >> >>
> > >> >> available, and
> > >> >>
> > >> >>> so on; but the last 2M train does not necessarily make 3M trains
> > >> >>> available immediately. Both the last 2M and the first 4 must be
> > >> >>> purchased to make a 3M available, and so on. G trains in 1837
> > >> >>> also work
> > >>
> > >> this way.
> > >>
> > >> >> ------------------------------------------------------------------
> > >> >> ---
> > >> >> -------
> > >> >> --
> > >> >>
> > >> >>> 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
> >
> > -------------------------------------------------------------------------
> > ----- 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
|
