rails-devel — List for discussion of Rails development

Re: [Rails-devel] Running to and through stations

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

Please read 1851 for 18AL. 

> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: vrijdag 1 juli 2011 23:19
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: [Rails-devel] Running to and through stations
> 
> Stefan (& others):
> 
> I'm having another look at the station properties that we have discussed a
> while ago.
> 
> Let's first state what my approach would probably be.
> 
> 1.  The City class will be renamed to HexStation, because that describes
best
> what it is: the relationship between a Station (a potential train stop on
a tile)
> and a Hex (where a tile with such a Station has been laid upon).
> It is this relationship that defines an actual train stop.
> 
> 2. The HexStation objects will provide you the station properties to be
> discussed below.
> 
> 3. The station properties can be defined in either MapHex (<Hex> in
> Map.xml) or in Tile (<Tile> in TileSet.xml), or both; in the last case,
<Hex>
> takes precedence, as it is more specific.
> 
> 4. In both places I propose to define these properties as a subtag
<Access>
> that has attributes that define the station properties. If necessary, a
> restriction could be added to one station on a multi-station tile, but I'm
not
> aware of any cases where we would need that (perhaps 1841 Venezia, but I
> think defaults would apply there).
> 
> 5. Hex defaults can be defined per hex type (colour) in Map.xml and Tile
> defaults can be defined per tile station type (town, city) in TileSet.xml.
> 
> Now the question arises what attributes and values we need.  Your approach
> was a bit different from mine - in fact part of it is exactly orthogonal
to mine.
> 
> In a different thread I had already proposed the following two attributes:
> 
> - runTo={no|yes|tokenOnly}.  "no" would apply to e.g. Birmingham in 18AL
> before phase 4 and Elsaß-Lothringen in 1835 except in phase 2. "tokenOnly"
> would apply to the 18Scan red cities. The "no" examples imply that this
> property should be settable as a result of phase changes.  Would that be
> helpful?
> 
> - runThrough={no|yes|tokenOnly}. "no" would apply to e.g. standard off-
> map areas, "tokenOnly" would apply to 1830 Altoona (PRR base). Your values
> "RunThrough" and "NoAccess" for closedStationAllows suggest that I should
> also add "always" (or "evenIfClosed") and "notIfClosed", but do we really
> need these values? Where?
> 
> I would think that runTo and runThrough would better describe the kind of
> conditions that you would be looking for when you are constructing routes,
> than the openStationAllows and closedStationAllows attributes that you
> propose, but of course I may be wrong.  It's really up to you.
> 
> Not mentioned by me before, but inspired by your proposal:
> 
> - loop={yes|no}. This defines whether one train may visit a hex/tile more
> than once. This would replace your station naming proposal. I think this
is
> simpler.
> 
> - type={major|minor|medium} as you propose, except that I have added
> medium, which appears in some games.  IMO this station type would be
> train-independent; train-specific usage of station types is to be defined
per
> train type.  It could be useful in some cases where the tile looks like a
town,
> or is internally defined as a town (such as most off-map areas), but is
actually
> a non-tokenable city.
> 
> 
> Finally two questions about your proposal:
> 
> 1. Is there any semantic difference between runFrom and runTo? To me,
> these words describe exactly the same aspects, at least in the 18xx
universe,
> where trains run directionless (perhaps I should say that "to" and "from"
> are quantum-superimposed?).
> 
> 2. Do we really need N/A?  I’d say:  if it does not matter, it does not
matter.
> 
> Erik.
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > Verzonden: woensdag 15 juni 2011 7:11
> > Aan: 'Development list for Rails: an 18xx game'
> > Onderwerp: Re: [Rails-devel] 1830 Reading
> >
> > Erik:
> >
> > is there any reason, why you put the driveThroughStation on map.xml
> > instead in tile.xml, other than the one discusses previously, that
> tiles.xml is
> > not game specific?
> >
> > However the tiles you defined are (very) game specific already.
> >
> > Both from logical and implementation issues I would prefer to define
> > attributes of stations in the station tag instead of the hex tag.
> >
> > Coalfields:
> > For the coalfield hex a mechanism to buy the coalfield tokens is
> > needed
> first.
> > Then it is easy to add the adjustment to the revenue calculator via
> > the
> static
> > modifier approach similar to the bonus tokens.
> >
> > Stefan
> >
> > By the way:
> >
> > I have thought about similar issues in my mailing last year (04/29/10)
> > on "Changes to the Station objects", which cover some more cases due
> > to a more general approach.
> >
> > A) Each station adds the following (additional) attributes:
> >
> > tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid
> > it allows to run through, to run from or no access?
> >
> > openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is
> > laid
> it
> > allows to run through, to run to or none?
> >
> > closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the
> > station is fully tokened and the company does not own a token there,
> > what are the possibilities?
> >
> > To allow an easier definition I suggest to use station type
> > definitions
> like the
> > company types etc.
> >
> > A station is closed if the number of tokens equals the number of
> > slots, otherwise it is open.
> >
> > By this definition a town is always closed, but by setting
> closedStationAllows
> > to RunThrough that is not an issue.
> >
> > B) Different off-board locations:
> > There is a substantial variation of different kind of off-board
locations.
> > There are at least four cases, may be more.
> >
> > 1) Standard off-board locations (as in 1830) The off-board areas act
> > as
> sinks
> > for all companies.
> > No tokens allowed.
> > (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> > RunTo)
> >
> > 2) Tokenable off-board locations (example: SP base in 1870) A base
> > token
> can
> > be layed in at least one of the areas.
> > The rules claim that off-board areas are still sink for all companies,
> except for
> > the company with a token which can start a train there.
> > But it cannot run its trains through the hex (thus SP cannot have the
> > same train enter from NE and then continue to the E).
> >
> > (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows
> > =
> > RunTo)
> >
> > 3) Run-through off-board locations (as Hamburg in 18EU) A
> > non-tokenable station (similar to towns), that allows running through
it.
> >
> > (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> > RunThrough)
> >
> > And another from an non-implemented game:
> > 4) Tokenable run-to off-board locations (as in 18Scan) Here a
> > base-token
> is
> > needed to run to the station.
> >
> > (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> > closedStationAllows =
> > NoAccess)
> >
> > In  general a station is fully tokened if the nb of slots equals the
> > nb of
> tokens.
> > This implies that (default) towns are fully tokened (0=0), but the
> > fullyTokened attribute would be set to RunThrough.
> >
> > StationTypes should be added to provide defaults.
> >
> > C) Other new station attributes
> > runStationType = {Major, Minor}
> > Is it counted as city-type or town-type for plus-trains and
> express-trains?
> >
> > name = {...}
> > I would like to add is a "name" attribute for stations on tiles.
> > Identical
> names
> > would imply that those stations are mutually exclusive for train runs.
> They
> > would be automatically added to the list of exclusions to the revenue
> > calculator.
> 
> 
>
----------------------------------------------------------------------------
--
> 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

Re: [Rails-devel] Running to and through stations

[Chris S. <chr...@gm...>]

Will this proposal address halts, as in 1860, and distinguish them from small stations?

--
Chris Shaffer

Please consider the environment before printing this email.

On Jul 1, 2011, at 2:19 PM, "Erik Vos" <eri...@xs...> wrote:

> Stefan (& others):
> 
> I'm having another look at the station properties that we have discussed a
> while ago.
> 
> Let's first state what my approach would probably be.
> 
> 1.  The City class will be renamed to HexStation, because that describes
> best what it is: the relationship between a Station (a potential train stop
> on a tile) and a Hex (where a tile with such a Station has been laid upon).
> It is this relationship that defines an actual train stop.
> 
> 2. The HexStation objects will provide you the station properties to be
> discussed below. 
> 
> 3. The station properties can be defined in either MapHex (<Hex> in Map.xml)
> or in Tile (<Tile> in TileSet.xml), or both; in the last case, <Hex> takes
> precedence, as it is more specific.
> 
> 4. In both places I propose to define these properties as a subtag <Access>
> that has attributes that define the station properties. If necessary, a
> restriction could be added to one station on a multi-station tile, but I'm
> not aware of any cases where we would need that (perhaps 1841 Venezia, but I
> think defaults would apply there).
> 
> 5. Hex defaults can be defined per hex type (colour) in Map.xml and Tile
> defaults can be defined per tile station type (town, city) in TileSet.xml.
> 
> Now the question arises what attributes and values we need.  Your approach
> was a bit different from mine - in fact part of it is exactly orthogonal to
> mine.
> 
> In a different thread I had already proposed the following two attributes:
> 
> - runTo={no|yes|tokenOnly}.  "no" would apply to e.g. Birmingham in 18AL
> before phase 4 and Elsaß-Lothringen in 1835 except in phase 2. "tokenOnly"
> would apply to the 18Scan red cities. The "no" examples imply that this
> property should be settable as a result of phase changes.  Would that be
> helpful?
> 
> - runThrough={no|yes|tokenOnly}. "no" would apply to e.g. standard off-map
> areas, "tokenOnly" would apply to 1830 Altoona (PRR base). Your values
> "RunThrough" and "NoAccess" for closedStationAllows suggest that I should
> also add "always" (or "evenIfClosed") and "notIfClosed", but do we really
> need these values? Where?
> 
> I would think that runTo and runThrough would better describe the kind of
> conditions that you would be looking for when you are constructing routes,
> than the openStationAllows and closedStationAllows attributes that you
> propose, but of course I may be wrong.  It's really up to you.
> 
> Not mentioned by me before, but inspired by your proposal:
> 
> - loop={yes|no}. This defines whether one train may visit a hex/tile more
> than once. This would replace your station naming proposal. I think this is
> simpler.
> 
> - type={major|minor|medium} as you propose, except that I have added medium,
> which appears in some games.  IMO this station type would be
> train-independent; train-specific usage of station types is to be defined
> per train type.  It could be useful in some cases where the tile looks like
> a town, or is internally defined as a town (such as most off-map areas), but
> is actually a non-tokenable city.
> 
> 
> Finally two questions about your proposal:
> 
> 1. Is there any semantic difference between runFrom and runTo? To me, these
> words describe exactly the same aspects, at least in the 18xx universe,
> where trains run directionless (perhaps I should say that "to" and "from"
> are quantum-superimposed?).
> 
> 2. Do we really need N/A?  I’d say:  if it does not matter, it does not
> matter.
> 
> Erik.
> 
> 
>> -----Oorspronkelijk bericht-----
>> Van: Stefan Frey [mailto:ste...@we...]
>> Verzonden: woensdag 15 juni 2011 7:11
>> Aan: 'Development list for Rails: an 18xx game'
>> Onderwerp: Re: [Rails-devel] 1830 Reading
>> 
>> Erik:
>> 
>> is there any reason, why you put the driveThroughStation on map.xml
>> instead in tile.xml, other than the one discusses previously, that
> tiles.xml is
>> not game specific?
>> 
>> However the tiles you defined are (very) game specific already.
>> 
>> Both from logical and implementation issues I would prefer to define
>> attributes of stations in the station tag instead of the hex tag.
>> 
>> Coalfields:
>> For the coalfield hex a mechanism to buy the coalfield tokens is needed
> first.
>> Then it is easy to add the adjustment to the revenue calculator via the
> static
>> modifier approach similar to the bonus tokens.
>> 
>> Stefan
>> 
>> By the way:
>> 
>> I have thought about similar issues in my mailing last year (04/29/10) on
>> "Changes to the Station objects", which cover some more cases due to a
>> more general approach.
>> 
>> A) Each station adds the following (additional) attributes:
>> 
>> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid it
>> allows to run through, to run from or no access?
>> 
>> openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is laid
> it
>> allows to run through, to run to or none?
>> 
>> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the station is
>> fully tokened and the company does not own a token there, what are the
>> possibilities?
>> 
>> To allow an easier definition I suggest to use station type definitions
> like the
>> company types etc.
>> 
>> A station is closed if the number of tokens equals the number of slots,
>> otherwise it is open.
>> 
>> By this definition a town is always closed, but by setting
> closedStationAllows
>> to RunThrough that is not an issue.
>> 
>> B) Different off-board locations:
>> There is a substantial variation of different kind of off-board locations.
>> There are at least four cases, may be more.
>> 
>> 1) Standard off-board locations (as in 1830) The off-board areas act as
> sinks
>> for all companies.
>> No tokens allowed.
>> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
>> 
>> 2) Tokenable off-board locations (example: SP base in 1870) A base token
> can
>> be layed in at least one of the areas.
>> The rules claim that off-board areas are still sink for all companies,
> except for
>> the company with a token which can start a train there.
>> But it cannot run its trains through the hex (thus SP cannot have the same
>> train enter from NE and then continue to the E).
>> 
>> (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
>> RunTo)
>> 
>> 3) Run-through off-board locations (as Hamburg in 18EU) A non-tokenable
>> station (similar to towns), that allows running through it.
>> 
>> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
>> RunThrough)
>> 
>> And another from an non-implemented game:
>> 4) Tokenable run-to off-board locations (as in 18Scan) Here a base-token
> is
>> needed to run to the station.
>> 
>> (tokenAllows = RunFrom, openStationAllows = NoAccess ,
>> closedStationAllows =
>> NoAccess)
>> 
>> In  general a station is fully tokened if the nb of slots equals the nb of
> tokens.
>> This implies that (default) towns are fully tokened (0=0), but the
>> fullyTokened attribute would be set to RunThrough.
>> 
>> StationTypes should be added to provide defaults.
>> 
>> C) Other new station attributes
>> runStationType = {Major, Minor}
>> Is it counted as city-type or town-type for plus-trains and
> express-trains?
>> 
>> name = {...}
>> I would like to add is a "name" attribute for stations on tiles. Identical
> names
>> would imply that those stations are mutually exclusive for train runs.
> They
>> would be automatically added to the list of exclusions to the revenue
>> calculator.
> 
> 
> ------------------------------------------------------------------------------
> 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

[Rails-devel] Running to and through stations

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

Stefan (& others):

I'm having another look at the station properties that we have discussed a
while ago.

Let's first state what my approach would probably be.

1.  The City class will be renamed to HexStation, because that describes
best what it is: the relationship between a Station (a potential train stop
on a tile) and a Hex (where a tile with such a Station has been laid upon).
It is this relationship that defines an actual train stop.

2. The HexStation objects will provide you the station properties to be
discussed below. 

3. The station properties can be defined in either MapHex (<Hex> in Map.xml)
or in Tile (<Tile> in TileSet.xml), or both; in the last case, <Hex> takes
precedence, as it is more specific.

4. In both places I propose to define these properties as a subtag <Access>
that has attributes that define the station properties. If necessary, a
restriction could be added to one station on a multi-station tile, but I'm
not aware of any cases where we would need that (perhaps 1841 Venezia, but I
think defaults would apply there).

5. Hex defaults can be defined per hex type (colour) in Map.xml and Tile
defaults can be defined per tile station type (town, city) in TileSet.xml.

Now the question arises what attributes and values we need.  Your approach
was a bit different from mine - in fact part of it is exactly orthogonal to
mine.

In a different thread I had already proposed the following two attributes:

- runTo={no|yes|tokenOnly}.  "no" would apply to e.g. Birmingham in 18AL
before phase 4 and Elsaß-Lothringen in 1835 except in phase 2. "tokenOnly"
would apply to the 18Scan red cities. The "no" examples imply that this
property should be settable as a result of phase changes.  Would that be
helpful?
 
- runThrough={no|yes|tokenOnly}. "no" would apply to e.g. standard off-map
areas, "tokenOnly" would apply to 1830 Altoona (PRR base). Your values
"RunThrough" and "NoAccess" for closedStationAllows suggest that I should
also add "always" (or "evenIfClosed") and "notIfClosed", but do we really
need these values? Where?

I would think that runTo and runThrough would better describe the kind of
conditions that you would be looking for when you are constructing routes,
than the openStationAllows and closedStationAllows attributes that you
propose, but of course I may be wrong.  It's really up to you.

Not mentioned by me before, but inspired by your proposal:

- loop={yes|no}. This defines whether one train may visit a hex/tile more
than once. This would replace your station naming proposal. I think this is
simpler.

- type={major|minor|medium} as you propose, except that I have added medium,
which appears in some games.  IMO this station type would be
train-independent; train-specific usage of station types is to be defined
per train type.  It could be useful in some cases where the tile looks like
a town, or is internally defined as a town (such as most off-map areas), but
is actually a non-tokenable city.


Finally two questions about your proposal:

1. Is there any semantic difference between runFrom and runTo? To me, these
words describe exactly the same aspects, at least in the 18xx universe,
where trains run directionless (perhaps I should say that "to" and "from"
are quantum-superimposed?).

2. Do we really need N/A?  I’d say:  if it does not matter, it does not
matter.

Erik.


> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: woensdag 15 juni 2011 7:11
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: Re: [Rails-devel] 1830 Reading
> 
> Erik:
> 
> is there any reason, why you put the driveThroughStation on map.xml
> instead in tile.xml, other than the one discusses previously, that
tiles.xml is
> not game specific?
> 
> However the tiles you defined are (very) game specific already.
> 
> Both from logical and implementation issues I would prefer to define
> attributes of stations in the station tag instead of the hex tag.
> 
> Coalfields:
> For the coalfield hex a mechanism to buy the coalfield tokens is needed
first.
> Then it is easy to add the adjustment to the revenue calculator via the
static
> modifier approach similar to the bonus tokens.
> 
> Stefan
> 
> By the way:
> 
> I have thought about similar issues in my mailing last year (04/29/10) on
> "Changes to the Station objects", which cover some more cases due to a
> more general approach.
> 
> A) Each station adds the following (additional) attributes:
> 
> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A} If a token is laid it
> allows to run through, to run from or no access?
> 
> openStationAllows = {RunThrough, RunTo, NoAccess, N/A} If a token is laid
it
> allows to run through, to run to or none?
> 
> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A} If the station is
> fully tokened and the company does not own a token there, what are the
> possibilities?
> 
> To allow an easier definition I suggest to use station type definitions
like the
> company types etc.
> 
> A station is closed if the number of tokens equals the number of slots,
> otherwise it is open.
> 
> By this definition a town is always closed, but by setting
closedStationAllows
> to RunThrough that is not an issue.
> 
> B) Different off-board locations:
> There is a substantial variation of different kind of off-board locations.
> There are at least four cases, may be more.
> 
> 1) Standard off-board locations (as in 1830) The off-board areas act as
sinks
> for all companies.
> No tokens allowed.
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
> 
> 2) Tokenable off-board locations (example: SP base in 1870) A base token
can
> be layed in at least one of the areas.
> The rules claim that off-board areas are still sink for all companies,
except for
> the company with a token which can start a train there.
> But it cannot run its trains through the hex (thus SP cannot have the same
> train enter from NE and then continue to the E).
> 
> (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
> RunTo)
> 
> 3) Run-through off-board locations (as Hamburg in 18EU) A non-tokenable
> station (similar to towns), that allows running through it.
> 
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> RunThrough)
> 
> And another from an non-implemented game:
> 4) Tokenable run-to off-board locations (as in 18Scan) Here a base-token
is
> needed to run to the station.
> 
> (tokenAllows = RunFrom, openStationAllows = NoAccess ,
> closedStationAllows =
> NoAccess)
> 
> In  general a station is fully tokened if the nb of slots equals the nb of
tokens.
> This implies that (default) towns are fully tokened (0=0), but the
> fullyTokened attribute would be set to RunThrough.
> 
> StationTypes should be added to provide defaults.
> 
> C) Other new station attributes
> runStationType = {Major, Minor}
> Is it counted as city-type or town-type for plus-trains and
express-trains?
> 
> name = {...}
> I would like to add is a "name" attribute for stations on tiles. Identical
names
> would imply that those stations are mutually exclusive for train runs.
They
> would be automatically added to the list of exclusions to the revenue
> calculator.

Re: [Rails-devel] Coalfields and states

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

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

Re: [Rails-devel] Coalfields and states

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

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

[Rails-devel] Coalfields and states

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

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

Re: [Rails-devel] Subphases

[brett l. <bre...@gm...>]

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 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
>

Re: [Rails-devel] Subphases

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

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 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

Re: [Rails-devel] Subphases

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

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 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

Re: [Rails-devel] Subphases

[brett l. <bre...@gm...>]

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 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
>

Re: [Rails-devel] Subphases

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

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 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

Re: [Rails-devel] Subphases

[John D. G. <jd...@di...>]

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.

Re: [Rails-devel] Subphases

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

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> On 28 June 2011 17:08, Erik Vos <eri...@xs...> wrote:
> > BTW So far, phase names are only used internally and in the game
> > reports, but I suppose it makes sense to show the current phase name
> > somewhere in the UI.  The only place where it's  easy to find a spot
> > is the Game status window.
> 
> I think this is a good idea, would be nice to confirm obviously which
phase the
> game is in.

Done. That was VERY simple indeed!
Erik.

Re: [Rails-devel] Subphases

[Phil D. <de...@gm...>]

On 28 June 2011 17:08, Erik Vos <eri...@xs...> wrote:
> BTW So far, phase names are only used internally and in the game reports,
> but I suppose it makes sense to show the current phase name somewhere in the
> UI.  The only place where it's  easy to find a spot is the Game status
> window.

I think this is a good idea, would be nice to confirm obviously which
phase the game is in.


> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: Phil Davies [mailto:de...@gm...]
>> Verzonden: dinsdag 28 juni 2011 11:54
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Subphases
>>
>> I'd agree that this seems like a sensible approach, although in
> terminology I
>> think I would lean more towards calling the phases 3.1 and 6.1 or similar.
> For
>> games like TN where they are noted in the rules, there is no reason you
> can't
>> call them 3.5/6.5 to keep in line with the rules as written.  However, for
>> games where the rules simply state 'X happens on the sale of the 2nd 6
> train'
>> then we could call that phase 6.1, since something else might happen on
> the
>> sale of the 3rd 6 train, and that could be phase 6.2...or similar.
>>
>> I feel that a decimal notation gives you more flexibility.
>>
>>
>>
>> On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
>> > I’m looking for a generic solution for actions to be triggered by
>> > buying any train, and it seems to me that this can best be
>> > accomplished by somewhat extending the Phase concept.
>> >
>> > The 18TN rules (that have triggered these musings) already point in
>> > this direction by defining two ‘subphases’: 3½ for the Civil War, and
>> > 6½ for obsoleting the 4-trains.
>> >
>> > I vaguely remember that a few other games also have such ‘subphases’ –
>> > does anyone have an overview?
>> >
>> >
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> >
>> >
>> > [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.
>> >
>> >
>> >
>> > So in 18TN we would add extra phases 3½ and 6½.  Configuring such
>> > subphases will be similar to the existing stopgap for phase 6½.
>> > Perhaps it makes sense to define all phase changes in a new tag, so
>> > that we would end up with (for 18TN):
>> >
>> >       <TrainType name="6" majorStops="6" cost="630" quantity="2">
>> >
>> > <NewPhase id="6"/> (default train index remains “1”).
>> >
>> >             <NewPhase trainIndex="2" id="6½"/>
>> >
>> >       </TrainType>
>> >
>> > and
>> >
>> >       <Phase name="3½">
>> >
>> >             <Condition name="CivilWar" value="yes"/> (the value is
>> > redundant, but I would like to save such conditions in a HashMap so
>> > that multiple values are not excluded).
>> >
>> >       </Phase>
>> >
>> > ...
>> >
>> >       <Phase name="6">
>> >
>> >             <Tiles colour="yellow,green,brown"/>  (probably redundant,
>> > as phase 5 already has this property).
>> >
>> >             <Trains rust="3"/>
>> >
>> >       </Phase>
>> >
>> >       <Phase name="6½">
>> >
>> >             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we
>> > can also leave ‘obsolete’ being a train property, as it is now).
>> >
>> >       </Phase>
>> >
>> >
>> >
>> > Erik.
>> >
>> >
>> >
>> >
>> >
>> > Van: Scott Petersen [mailto:sc...@re...]
>> > Verzonden: vrijdag 17 juni 2011 23:53
>> > Aan: Development list for Rails: an 18xx game
>> > Onderwerp: Re: [Rails-devel] Train management
>> >
>> >
>> >
>> > On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
>> >
>> > OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work
> now.
>> >
>> >
>> >
>> > The implementation is a bit provisional, as it only covers rusting
>> > yet.  I think we’ll have to move to a more generic approach, in which
>> > any type of action can be triggered that is normally associated with
> phase
>> changes.
>> >
>> >
>> >
>> > Erik, I played through a test game and verify that the second 6-train
>> > rusts the 4-trains.
>> >
>> > It looks like you implemented this with the following as a property of
>> > the 6-train.
>> >
>> >                                   <Sub index="2" rustedTrain="4"/>
>> >
>> >
>> >
>> > 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.
>> > All of those should not have the obsoleting property.  The only trains
>> > that obsolete are the 4-trains on the second 6-train (hard rust on
>> > 8-train).  As train obsoletion is currently implemented, it is just a
>> > "free pass" at another run once the train "rusts."  I think there is
>> > currently no mechanism to make the train hard rust immediately,
> bypassing
>> the obsolete "free pass."
>> >
>> >
>> >
>> > As you said, we will have to take a look at a more general solution
>> > for the half-phase changes.
>> >
>> >
>> >
>> > Also, it would be nice to implement the "you must buy a train unless
>> > you have no route" red text once obsolete trains are run and leave a
>> > company trainless.  This must currently be triggered off something
>> > like a dividend of zero because it does not appear after a company's
>> > obsolete trains run and rust.
>> >
>> > ----------------------------------------------------------------------
>> > -------- 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
>

Re: [Rails-devel] Subphases

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

We don't need to predefine any particular scheme for naming phases. All such
names are just alphanumeric identifiers. So we can follow the names defined
in the rules, and assign whatever looks appropriate if we have to invent
names. For Rails it's immaterial if subphase names look like "6a" or "6½" or
"6.1" or "6.5". Or "VIbis".

BTW So far, phase names are only used internally and in the game reports,
but I suppose it makes sense to show the current phase name somewhere in the
UI.  The only place where it's  easy to find a spot is the Game status
window.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> Verzonden: dinsdag 28 juni 2011 11:54
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Subphases
> 
> I'd agree that this seems like a sensible approach, although in
terminology I
> think I would lean more towards calling the phases 3.1 and 6.1 or similar.
For
> games like TN where they are noted in the rules, there is no reason you
can't
> call them 3.5/6.5 to keep in line with the rules as written.  However, for
> games where the rules simply state 'X happens on the sale of the 2nd 6
train'
> then we could call that phase 6.1, since something else might happen on
the
> sale of the 3rd 6 train, and that could be phase 6.2...or similar.
> 
> I feel that a decimal notation gives you more flexibility.
> 
> 
> 
> On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
> > I’m looking for a generic solution for actions to be triggered by
> > buying any train, and it seems to me that this can best be
> > accomplished by somewhat extending the Phase concept.
> >
> > The 18TN rules (that have triggered these musings) already point in
> > this direction by defining two ‘subphases’: 3½ for the Civil War, and
> > 6½ for obsoleting the 4-trains.
> >
> > I vaguely remember that a few other games also have such ‘subphases’ –
> > does anyone have an overview?
> >
> >
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> >
> >
> > [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.
> >
> >
> >
> > So in 18TN we would add extra phases 3½ and 6½.  Configuring such
> > subphases will be similar to the existing stopgap for phase 6½.
> > Perhaps it makes sense to define all phase changes in a new tag, so
> > that we would end up with (for 18TN):
> >
> >       <TrainType name="6" majorStops="6" cost="630" quantity="2">
> >
> > <NewPhase id="6"/> (default train index remains “1”).
> >
> >             <NewPhase trainIndex="2" id="6½"/>
> >
> >       </TrainType>
> >
> > and
> >
> >       <Phase name="3½">
> >
> >             <Condition name="CivilWar" value="yes"/> (the value is
> > redundant, but I would like to save such conditions in a HashMap so
> > that multiple values are not excluded).
> >
> >       </Phase>
> >
> > ...
> >
> >       <Phase name="6">
> >
> >             <Tiles colour="yellow,green,brown"/>  (probably redundant,
> > as phase 5 already has this property).
> >
> >             <Trains rust="3"/>
> >
> >       </Phase>
> >
> >       <Phase name="6½">
> >
> >             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we
> > can also leave ‘obsolete’ being a train property, as it is now).
> >
> >       </Phase>
> >
> >
> >
> > Erik.
> >
> >
> >
> >
> >
> > Van: Scott Petersen [mailto:sc...@re...]
> > Verzonden: vrijdag 17 juni 2011 23:53
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Train management
> >
> >
> >
> > On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
> >
> > OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work
now.
> >
> >
> >
> > The implementation is a bit provisional, as it only covers rusting
> > yet.  I think we’ll have to move to a more generic approach, in which
> > any type of action can be triggered that is normally associated with
phase
> changes.
> >
> >
> >
> > Erik, I played through a test game and verify that the second 6-train
> > rusts the 4-trains.
> >
> > It looks like you implemented this with the following as a property of
> > the 6-train.
> >
> >                                   <Sub index="2" rustedTrain="4"/>
> >
> >
> >
> > 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.
> > All of those should not have the obsoleting property.  The only trains
> > that obsolete are the 4-trains on the second 6-train (hard rust on
> > 8-train).  As train obsoletion is currently implemented, it is just a
> > "free pass" at another run once the train "rusts."  I think there is
> > currently no mechanism to make the train hard rust immediately,
bypassing
> the obsolete "free pass."
> >
> >
> >
> > As you said, we will have to take a look at a more general solution
> > for the half-phase changes.
> >
> >
> >
> > Also, it would be nice to implement the "you must buy a train unless
> > you have no route" red text once obsolete trains are run and leave a
> > company trainless.  This must currently be triggered off something
> > like a dividend of zero because it does not appear after a company's
> > obsolete trains run and rust.
> >
> > ----------------------------------------------------------------------
> > -------- 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

Re: [Rails-devel] Subphases

[brett l. <bre...@gm...>]

On Tue, Jun 28, 2011 at 2:53 AM, Phil Davies <de...@gm...> wrote:
> I'd agree that this seems like a sensible approach, although in
> terminology I think I would lean more towards calling the phases 3.1
> and 6.1 or similar.  For games like TN where they are noted in the
> rules, there is no reason you can't call them 3.5/6.5 to keep in line
> with the rules as written.  However, for games where the rules simply
> state 'X happens on the sale of the 2nd 6 train' then we could call
> that phase 6.1, since something else might happen on the sale of the
> 3rd 6 train, and that could be phase 6.2...or similar.
>
> I feel that a decimal notation gives you more flexibility.
>

+1 on both counts.

The proposal looks reasonable, but I agree with favoring decimal notation.

---Brett.

Re: [Rails-devel] Subphases

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

>Van: Scott Petersen [mailto:sc...@re...] 

>Note that for the 18TN Civil War, each company needs a temporary condition
which is removed once it runs with the Civil War run (non-counted train).
I've not played it enough to know, but I think due to stock price movement,
the Civil War might not all happen sequentially.  For example, if it is
triggered shortly before an SR and a company runs it's CW run before the SR,
then the SR has stock price movement, the company that already did a CW run
might run before one that has not done its CW run.

Yes, that's right.  It may be better to probably better to formulate the
Civil War as an immediate action that triggers setting the per-company
condition in an 18TN special class.  We'll see.

Erik.

Re: [Rails-devel] Subphases

[Scott P. <sc...@re...>]

On Tue, Jun 28, 2011 at 4:44 AM, Erik Vos <eri...@xs...> wrote:

> I vaguely remember that a few other games also have such ‘subphases’ – does
> anyone have an overview?
>

I think the only other game with a half phase is 18Mex--it is a well-liked
game and I expect that there is significant player interest in it.  1880 has
the special rule that a Stock Round is executed when the last train of a
rank is purchased (there is another condition too--no train purchased since
the company last ran).  There are probably lots of examples of delayed
actions that could be done as in your case 3.

Note that for the 18TN Civil War, each company needs a temporary condition
which is removed once it runs with the Civil War run (non-counted train).
 I've not played it enough to know, but I think due to stock price movement,
the Civil War might not all happen sequentially.  For example, if it is
triggered shortly before an SR and a company runs it's CW run before the SR,
then the SR has stock price movement, the company that already did a CW run
might run before one that has not done its CW run.

Re: [Rails-devel] Subphases

[Phil D. <de...@gm...>]

I'd agree that this seems like a sensible approach, although in
terminology I think I would lean more towards calling the phases 3.1
and 6.1 or similar.  For games like TN where they are noted in the
rules, there is no reason you can't call them 3.5/6.5 to keep in line
with the rules as written.  However, for games where the rules simply
state 'X happens on the sale of the 2nd 6 train' then we could call
that phase 6.1, since something else might happen on the sale of the
3rd 6 train, and that could be phase 6.2...or similar.

I feel that a decimal notation gives you more flexibility.



On 28 June 2011 10:44, Erik Vos <eri...@xs...> wrote:
> I’m looking for a generic solution for actions to be triggered by buying any
> train, and it seems to me that this can best be accomplished by somewhat
> extending the Phase concept.
>
> The 18TN rules (that have triggered these musings) already point in this
> direction by defining two ‘subphases’: 3½ for the Civil War, and 6½ for
> obsoleting the 4-trains.
>
> I vaguely remember that a few other games also have such ‘subphases’ – does
> anyone have an overview?
>
>
>
> 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.
>
> 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.
>
> 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.
>
>
>
> [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.
>
>
>
> So in 18TN we would add extra phases 3½ and 6½.  Configuring such subphases
> will be similar to the existing stopgap for phase 6½.  Perhaps it makes
> sense to define all phase changes in a new tag, so that we would end up with
> (for 18TN):
>
>       <TrainType name="6" majorStops="6" cost="630" quantity="2">
>
> <NewPhase id="6"/> (default train index remains “1”).
>
>             <NewPhase trainIndex="2" id="6½"/>
>
>       </TrainType>
>
> and
>
>       <Phase name="3½">
>
>             <Condition name="CivilWar" value="yes"/> (the value is
> redundant, but I would like to save such conditions in a HashMap so that
> multiple values are not excluded).
>
>       </Phase>
>
> ...
>
>       <Phase name="6">
>
>             <Tiles colour="yellow,green,brown"/>  (probably redundant, as
> phase 5 already has this property).
>
>             <Trains rust="3"/>
>
>       </Phase>
>
>       <Phase name="6½">
>
>             <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we can
> also leave ‘obsolete’ being a train property, as it is now).
>
>       </Phase>
>
>
>
> Erik.
>
>
>
>
>
> Van: Scott Petersen [mailto:sc...@re...]
> Verzonden: vrijdag 17 juni 2011 23:53
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management
>
>
>
> On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:
>
> OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.
>
>
>
> The implementation is a bit provisional, as it only covers rusting yet.  I
> think we’ll have to move to a more generic approach, in which any type of
> action can be triggered that is normally associated with phase changes.
>
>
>
> Erik, I played through a test game and verify that the second 6-train rusts
> the 4-trains.
>
> It looks like you implemented this with the following as a property of the
> 6-train.
>
>                                   <Sub index="2" rustedTrain="4"/>
>
>
>
> 18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.  All
> of those should not have the obsoleting property.  The only trains that
> obsolete are the 4-trains on the second 6-train (hard rust on 8-train).  As
> train obsoletion is currently implemented, it is just a "free pass" at
> another run once the train "rusts."  I think there is currently no mechanism
> to make the train hard rust immediately, bypassing the obsolete "free pass."
>
>
>
> As you said, we will have to take a look at a more general solution for the
> half-phase changes.
>
>
>
> Also, it would be nice to implement the "you must buy a train unless you
> have no route" red text once obsolete trains are run and leave a company
> trainless.  This must currently be triggered off something like a dividend
> of zero because it does not appear after a company's obsolete trains run and
> rust.
>
> ------------------------------------------------------------------------------
> 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
>
>

[Rails-devel] Subphases

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

I’m looking for a generic solution for actions to be triggered by buying any
train, and it seems to me that this can best be accomplished by somewhat
extending the Phase concept.

The 18TN rules (that have triggered these musings) already point in this
direction by defining two ‘subphases’: 3½ for the Civil War, and 6½ for
obsoleting the 4-trains.

I vaguely remember that a few other games also have such ‘subphases’ – does
anyone have an overview?

 

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.

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.

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.

 

[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.

 

So in 18TN we would add extra phases 3½ and 6½.  Configuring such subphases
will be similar to the existing stopgap for phase 6½.  Perhaps it makes
sense to define all phase changes in a new tag, so that we would end up with
(for 18TN):

      <TrainType name="6" majorStops="6" cost="630" quantity="2">

<NewPhase id="6"/> (default train index remains “1”).

            <NewPhase trainIndex="2" id="6½"/>

      </TrainType>

and

      <Phase name="3½">

            <Condition name="CivilWar" value="yes"/> (the value is
redundant, but I would like to save such conditions in a HashMap so that
multiple values are not excluded).

      </Phase>

...

      <Phase name="6">

            <Tiles colour="yellow,green,brown"/>  (probably redundant, as
phase 5 already has this property).

            <Trains rust="3"/>

      </Phase>

      <Phase name="6½">

            <Trains rust="4"/>  (perhaps with obsolete=”yes”, but we can
also leave ‘obsolete’ being a train property, as it is now).

      </Phase>

 

Erik.

 

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: vrijdag 17 juni 2011 23:53
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

On Thu, Jun 9, 2011 at 5:17 PM, Erik Vos <eri...@xs...> wrote:

OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.

 

The implementation is a bit provisional, as it only covers rusting yet.  I
think we’ll have to move to a more generic approach, in which any type of
action can be triggered that is normally associated with phase changes.

 

Erik, I played through a test game and verify that the second 6-train rusts
the 4-trains.  

It looks like you implemented this with the following as a property of the
6-train.

                                  <Sub index="2" rustedTrain="4"/>

 

18TN's Game.xml is currently configured to obsolete the 2/3/4-trains.  All
of those should not have the obsoleting property.  The only trains that
obsolete are the 4-trains on the second 6-train (hard rust on 8-train).  As
train obsoletion is currently implemented, it is just a "free pass" at
another run once the train "rusts."  I think there is currently no mechanism
to make the train hard rust immediately, bypassing the obsolete "free pass."

 

As you said, we will have to take a look at a more general solution for the
half-phase changes.

 

Also, it would be nice to implement the "you must buy a train unless you
have no route" red text once obsolete trains are run and leave a company
trainless.  This must currently be triggered off something like a dividend
of zero because it does not appear after a company's obsolete trains run and
rust.

Re: [Rails-devel] 1826

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

OK, done.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: maandag 27 juni 2011 2:30
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] 1826

 

On Sun, Jun 26, 2011 at 3:57 AM, Erik Vos <eri...@xs...> wrote:

I had forgotten to include the layable tiles in TileSet.xml (and therefore
Tiles.xml), that's fixed now.

 

Thanks.  The attached patch adds the tile upgrade information to TileSet.xml
and trains and phase information to Game.xml.  There's obviously a lot more
work to do with Game.xml.

 

I'll see what I can do about adding a page to the wiki with all the special
rules next weekend. If someone wants to start to form a list in the
meantime, have at it.

 

Major hurdles are:

-Implement H trains

-Implement 5-share companies

-Mechanism for opening Etat/SNCF

Re: [Rails-devel] 18GA

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

Thanks.  

Great that we have got another game completed.

 

Erik.

 

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: zondag 26 juni 2011 14:47
Aan: Development list for Rails: an 18xx game
Onderwerp: [Rails-devel] 18GA

 

I found a couple bugs in 18GA.  They are fixed in the attached patch:

-Changed Atlanta brown tile from value 60 to 70 (the svg tile still needs to
be changed).

-Changed Macon brown from one city spot to two.

-Removed Savannah tiles from Cotton Port Variant (not needed in the
variant).

 

Also

-Moved the game out of prototype status now that everything is implemented.

-Added game copyright text.

 

I played a live game last night and everything worked okay except the bugs
above--which I was able to fix as we played. :-)

Re: [Rails-devel] 1826

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

I had forgotten to include the layable tiles in TileSet.xml (and therefore
Tiles.xml), that's fixed now.

 

Van: Erik Vos [mailto:eri...@xs...] 
Verzonden: zaterdag 25 juni 2011 17:51
Aan: 'Development list for Rails: an 18xx game'
Onderwerp: Re: [Rails-devel] 1826

 

Yes, you're right. Done.

I also checked the layable tiles, but these all already exist.

 

Erik

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: zaterdag 25 juni 2011 16:21
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] 1826

 

On Sat, Jun 25, 2011 at 9:17 AM, Erik Vos <eri...@xs...> wrote:

I have done the missing special tiles.  Not sure if we also need to replace
the yellow and green tiles by ones that have negative numbers.  I think
there are one or two places where that could make a difference, so if needed
I'll replace these too.

 

Yes, I think we need to do that because when tiles are laid over those
hexes, they should not free up a tile for reuse.

Re: [Rails-devel] 1826

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

Yes, you're right. Done.

I also checked the layable tiles, but these all already exist.

 

Erik

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: zaterdag 25 juni 2011 16:21
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] 1826

 

On Sat, Jun 25, 2011 at 9:17 AM, Erik Vos <eri...@xs...> wrote:

I have done the missing special tiles.  Not sure if we also need to replace
the yellow and green tiles by ones that have negative numbers.  I think
there are one or two places where that could make a difference, so if needed
I'll replace these too.

 

Yes, I think we need to do that because when tiles are laid over those
hexes, they should not free up a tile for reuse.

Re: [Rails-devel] 1826

[Scott P. <sc...@re...>]

On Sat, Jun 25, 2011 at 9:17 AM, Erik Vos <eri...@xs...> wrote:

> I have done the missing special tiles.  Not sure if we also need to replace
> the yellow and green tiles by ones that have negative numbers.  I think
> there are one or two places where that could make a difference, so if needed
> I’ll replace these too.
>

Yes, I think we need to do that because when tiles are laid over those
hexes, they should not free up a tile for reuse.