Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@xs...> - 2011-06-30 23:02:51
|
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
|
|
From: Stefan F. <ste...@we...> - 2011-07-01 05:14:35
|
I agree that hashmapstate should be observable, however the rails solution before that was neither. But it is on my list for the refactoring, but not with the highest priority. Most likely it will be built on the GlazedList library. I am a little surprised that you did not add an attribute to the Bonus(Token) class instead of creating a new class. The mechanism to inform the Revenue Calculator is that Rights implements the Static RevenueModifier. Will be done next week. Stefan
Erik Vos <eri...@xs...> schrieb:
>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
|
|
From: Erik V. <eri...@xs...> - 2011-07-01 09:42:18
|
That's a lot of topics...
> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> I agree that hashmapstate should be observable, however the rails solution
> before that was neither.
OK, I'll see what I can do in the meantime to fix that.
> But it is on my list for the refactoring, but not with
> the highest priority. Most likely it will be built on the GlazedList
library.
Hmm, interesting. I don't yet see what these EventLists can do for us, but
we can discuss that later.
Keep in mind that we are heading for a client/server split, and then the
updates from the ModelObjects to the ViewObjects can no longer use the
Observer pattern as it works now. Would EventLists fix that?
>From my POV, I would like to have all ModelObjects being registered at some
central registry (GameManager?) as a new intermediate, but then we run into
the usual problem how our objects can find that registry. Currently Rails
uses three different ways in which objects get access to the GameManager,
but none of these I find completely satisfactory. But that's a separate
discussion.
> I am a
> little surprised that you did not add an attribute to the Bonus(Token)
class
> instead of creating a new class.
Not sure what your point is here. Merge Bonus and BonusToken? But Bonus is
not a drawable token.
> The mechanism to inform the Revenue
> Calculator is that Rights implements the Static RevenueModifier. Will be
done
> next week. Stefan
Great!
Erik.
>
> Erik Vos <eri...@xs...> schrieb:
>
> >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
> >> >> >> 5+something 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
>
>
>
----------------------------------------------------------------------------
--
> 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
|
|
From: Erik V. <eri...@xs...> - 2011-07-04 11:37:35
|
Undoing the Coalfields buy action is now visible in the UI. > > I agree that hashmapstate should be observable, however the rails > > solution before that was neither. > > OK, I'll see what I can do in the meantime to fix that. HashMapState now extends ModelObject. MapChange and RemoveFromMap now can take the ModelObject it is changing, and on execute() and undo() the model update() method is now called to update the Observers; this all works the same way as ArrayListState already did. The rights map now uses HashMapState directly. RightsModel has been removed. The RightsModel getText() method has been moved to HashMapState. I hope that the output will be usable for any future use of HashMapState that needs Observers. I have also updated ModelObject.update() to return immediately if there are no observers. This saves unnecessary overhead in constructing unused View text, as would be the case with the other current use of HashMapState, which is has no observers. Erik. |
|
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
|
|
From: Erik V. <eri...@xs...> - 2011-07-07 08:19:29
|
Thanks, Stefan. > 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? I would agree, but that's more because of the simplicity of interpreting the rules this way than that I'm any sort of rules expert.... > 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. Ah, good point. I had created Rights as a map so it could be used for more complex cases, but the value is currently unused and remains null. Would it help to use the location name as the value of this right? Any other ideas? In addition: would it be useful to give this hex (or HexStation) a special type once we have implemented that new concept? Here we could reuse type "mine", because that's a pretty generic type that occurs in several games. > 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. OK, I'll have a look. Yesterday I had the same problem with Phase. finishConfiguration() is intended to be generic in all configurable classes, but it's an afterthought and is so far only called where it is really used (and apparently not even that!). > 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. Well, right. But otherwise specific OperatingRound_1830 and PublicCompany_1830 classes would be needed to implement this feature, and I found that a bit of overkill too. But it's still an option. Would you have preferred that approach? The SpecialRight class would then also become specific and be renamed to CoalfieldsRight or so. I have no idea in what other games we could use Rights. As I have named it, it's very generic and could perhaps be employed in currently unexpected ways. But I must admit that I can't give any example, so maybe you're right. > 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 ;-) That could be so because of my rusty brains, of course. It's not so that I would run away if you started doing such things. But I think that it will be (1) a hell of a lot of work, and (2) pretty dangerous. Erik. |
|
From: Chris S. <chr...@gm...> - 2011-07-07 13:58:28
|
> > I have no idea in what other games we could use Rights. As I have named it, > it's very generic and could perhaps be employed in currently unexpected > ways. But I must admit that I can't give any example, so maybe you're > right. I have a memory of a game with a mine that requires purchase of the right to run through it. I think it was the Mesabi Range, and if my memory is correct it's a grey tile in the top middle of the board. -- Chris Please consider the environment before printing this e-mail. |
|
From: Scott P. <sc...@re...> - 2011-07-07 14:07:52
|
On Thu, Jul 7, 2011 at 8:58 AM, Chris Shaffer <chr...@gm...>wrote: > > I have a memory of a game with a mine that requires purchase of the right > to run through it. I think it was the Mesabi Range, and if my memory is > correct it's a grey tile in the top middle of the board. > Sure. That's 1850's Mesabi Range. It works like the 1830 Coalfields rights purchasing, but the $80 payment goes half to the owning company and half to the bank. If it is closed, the money goes to the bank. It also counts as the company's yellow tile lay. |
|
From: Scott P. <sc...@re...> - 2011-07-07 14:22:28
|
Here is the rules section on 1850's Mesabi Range. 6.5.1 The Mesabi Range The Mesabi Range is a special grey hex. To run to or through the Mesabi Range a company must pay the $80 cost for rights to the Mesabi Range. Paying for the Mesabi Range counts as a yellow tile lay. If the Mesabi Range private company has been closed, the money for the Mesabi range goes to the bank. If a public company owns the Mesabi Range private company, it receives half of the Mesabi Range connecting money with the rest going to the bank. The rights to the Mesabi Range may not be purchased until the Mesabi Range private company has been closed or sold to a public company. As there are only four Mesabi tokens, only four companies may have the rights to the Mesabi. |
|
From: Erik V. <eri...@xs...> - 2011-07-07 19:39:17
|
So that makes two, but this one is sufficiently different to require a special class anyway, so perhaps we should go that way for 1830 Coalfields as well, as Stefan implies. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: donderdag 7 juli 2011 16:22 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Coalfields and states Here is the rules section on 1850's Mesabi Range. 6.5.1 The Mesabi Range The Mesabi Range is a special grey hex. To run to or through the Mesabi Range a company must pay the $80 cost for rights to the Mesabi Range. Paying for the Mesabi Range counts as a yellow tile lay. If the Mesabi Range private company has been closed, the money for the Mesabi range goes to the bank. If a public company owns the Mesabi Range private company, it receives half of the Mesabi Range connecting money with the rest going to the bank. The rights to the Mesabi Range may not be purchased until the Mesabi Range private company has been closed or sold to a public company. As there are only four Mesabi tokens, only four companies may have the rights to the Mesabi. |
×
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