rails-devel — List for discussion of Rails development

[Rails-devel] Coalfields and rights

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> To solve the issue of the location I would simply add a location field to
the
> SpecialRights class and initialize that from XML.

OK, I have done that (and maybe overdone it by allowing multiple locations).

I'm thinking if we couldn't make Rights more useful by even further
generalizing it.  The next new special feature that I'm considering is the
18TN Civil War, which sets in with phase 3½, and involves that  each company
cannot use one of its trains at the next run - so this is important for you,
Stefan.  (The president can choose which train, but I guess we can safely
default to the smallest one). 

How to register such conditions?  I tend to treat it as a (temporary) right.
It's a negative right though - rather a liability than an asset - so should
we rename Right to the more neutral Condition?  Any better name?  To
distinguish between one-time and permanent rights/conditions/properties, we
could also turn it into a class and add a boolean attribute names oneTime or
such.

Erik.

Re: [Rails-devel] Coalfields and states

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

Interfaces are fine, but the trouble is that these must be implemented
somewhere. (I realise that you may have used the word 'interface' in a more
general sense, but let's then say: processes must be coded somewhere).

For now it's a matter of all or nothing, in other words: in the core or in a
game-specific class.  Do we have any other flavours?  

I think it's pretty pointless to try creating class hierarchies. Perhaps we
haven't done enough games yet, and one could think of common classes for
1830-style games, 1829-style games, OO games, etc., but I'm not really
convinced that such approaches would help us much. 

And I'm firmly against code duplication on a larger scale than the
unavoidable.  That's mainly why processes that occur in more than one game
tend to end up in the core.  And, indeed, I also tend to let slip through
very simple actions that are unique but take little code and therefore IMO
don't warrant creating game-specific classes on their own (but I'm willing
to change mind on this last point).

Perhaps your new grand scheme has a solution for all of this, but until we
have got a better idea of how that scheme looks like and works, the above is
the only way I can think about how to incorporate new features.

My mails are always too long, so I'll better defer my specific comments on
Rights to another one.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: vrijdag 8 juli 2011 9:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Coalfields and states
> 
> Here I would disagree for me it seems possible to model the Rights part of
> the Mesabi Range using the same class as Coalfields. However it will need
> further adjustments (of the same or other classes) to capture the full
ruling.
> 
> My main take is to keep the core code clean (and by this stable) for the
core
> rule set. This requires two things:
> 
> A) Defining what is the core code and provide Interfaces where special
rules
> can interact.
> 
> My current rule of thumb for the Rails code is that everything not called
> specific or special is current core code. And for me it contains code
which
> does not belong there, for example the support of Rights in OR and
> PublicCompany.
> Another example is some of code required for 1856.
> 
> B) Identify which are core rules/components.
> 
> My rule of thumb here is that core rules/components are those which are
> used by almost all games. (Almost all means except all except a few, taken
> from Probability Theory ;-)). All other rules are special/specific rules.
> 
> Examples for core rules/components are the existence of Corporations that
> lay tiles and tokens and are owner of trains and run those trains from
tokens
> on track defined by those tiles.
> 
> Usually the non-core rules are not that stable, so quite often they are
> substantially different in details. Examples are Merger rules.
> 
> As always there is not always black-and-white (define few?) but that is up
to
> us then to decide.
> 
> Important: This is not set in stone. If we identify mechanism which are
used
> so often and so stable that the qualify as core rules, the code of that
can be
> upgraded into the core code part. If we need further interfaces to
> incorporate new rules of yet unimplemented games or even yet uninvented
> games we identify those and add according interfaces to the core code.
> 
> The text got longer than intended, but that there my thoughts how to
design
> the RevenueCalculation package: Define the core part and then add
> interfaces to adopt  to the various little details.
> So I am curious how others think about that.
> 
> Stefan
> 
> 
> On Thursday, July 07, 2011 09:39:14 pm Erik Vos wrote:
> > So that makes two, but this one is sufficiently different to require a
> > special class anyway, so perhaps we should go that way for 1830
> > Coalfields as well, as Stefan implies.
> >
> > Erik.
> >
> >
> >
> > Van: Scott Petersen [mailto:sc...@re...]
> > Verzonden: donderdag 7 juli 2011 16:22
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Coalfields and states
> >
> >
> >
> > Here is the rules section on 1850's Mesabi Range.
> >
> >
> >
> > 6.5.1 The Mesabi Range
> >
> > The Mesabi Range is a special grey hex. To run to or
> >
> > through the Mesabi Range a company must pay the $80
> >
> > cost for rights to the Mesabi Range. Paying for the Mesabi
> >
> > Range counts as a yellow tile lay.
> >
> > If the Mesabi Range private company has been closed, the
> >
> > money for the Mesabi range goes to the bank. If a public
> >
> > company owns the Mesabi Range private company, it receives
> >
> > half of the Mesabi Range connecting money with
> >
> > the rest going to the bank.
> >
> > The rights to the Mesabi Range may not be purchased until
> >
> > the Mesabi Range private company has been closed or
> >
> > sold to a public company. As there are only four Mesabi
> >
> > tokens, only four companies may have the rights to the
> >
> > Mesabi.
> 
>
----------------------------------------------------------------------------
--
> 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...>]

Here I would disagree for me it seems possible to model the Rights part of the 
Mesabi Range using the same class as Coalfields. However it will need
further adjustments (of the same or other classes) to capture the full ruling.

My main take is to keep the core code clean (and by this stable) for the core 
rule set. This requires two things:

A) Defining what is the core code and provide Interfaces where special rules 
can interact.

My current rule of thumb for the Rails code is that everything not called 
specific or special is current core code. And for me it contains code which 
does not 
belong there, for example the support of Rights in OR and PublicCompany. 
Another example is some of code required for 1856.

B) Identify which are core rules/components.

My rule of thumb here is that core rules/components are those which are used 
by almost all games. (Almost all means except all except a few, taken from 
Probability Theory ;-)). All other rules are special/specific rules.

Examples for core rules/components are the existence of Corporations that lay 
tiles and tokens and are owner of trains and run those trains from tokens on 
track defined by those tiles.

Usually the non-core rules are not that stable, so quite often they are 
substantially different in details. Examples are Merger rules.

As always there is not always black-and-white (define few?) but that is up to 
us then to decide.

Important: This is not set in stone. If we identify mechanism which are used 
so often and so stable that the qualify as core rules, the code of that can be 
upgraded into the core code part. If we need further interfaces to incorporate 
new rules of yet unimplemented games or even yet uninvented games we identify 
those and add according interfaces to the core code.

The text got longer than intended, but that there my thoughts how to design 
the RevenueCalculation package: Define the core part and then add interfaces 
to adopt  to the various little details.
So I am curious how others think about that.

Stefan


On Thursday, July 07, 2011 09:39:14 pm Erik Vos wrote:
> So that makes two, but this one is sufficiently different to require a
> special class anyway, so perhaps we should go that way for 1830 Coalfields
> as well, as Stefan implies.
> 
> Erik.
> 
> 
> 
> Van: Scott Petersen [mailto:sc...@re...]
> Verzonden: donderdag 7 juli 2011 16:22
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Coalfields and states
> 
> 
> 
> Here is the rules section on 1850's Mesabi Range.
> 
> 
> 
> 6.5.1 The Mesabi Range
> 
> The Mesabi Range is a special grey hex. To run to or
> 
> through the Mesabi Range a company must pay the $80
> 
> cost for rights to the Mesabi Range. Paying for the Mesabi
> 
> Range counts as a yellow tile lay.
> 
> If the Mesabi Range private company has been closed, the
> 
> money for the Mesabi range goes to the bank. If a public
> 
> company owns the Mesabi Range private company, it receives
> 
> half of the Mesabi Range connecting money with
> 
> the rest going to the bank.
> 
> The rights to the Mesabi Range may not be purchased until
> 
> the Mesabi Range private company has been closed or
> 
> sold to a public company. As there are only four Mesabi
> 
> tokens, only four companies may have the rights to the
> 
> Mesabi.

Re: [Rails-devel] Coalfields and states

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

Erik:
To solve the issue of the location I would simply add a location field to the
SpecialRights class and initialize that from XML.

I am not an expert on those special properties etc., but it seems that only 
store the rights inside PublicCompany classes to be able to show it in the UI.
For the revenue calculation there is no need this could be replaced by 
allowing to figure out the owner of the special property from inside (e.g. 
adding a field owner) and adding a boolean field purchased.
Stefan

On Thursday, July 07, 2011 10:19:21 am Erik Vos wrote:
> Thanks, Stefan.
> 
> > A) Reading the rules carefully it seems that the rights are only required
> 
> for
> 
> > the revenue train run, not for tracing a route for tile and token laying.
> 
> Do all
> 
> > agree on this?
> 
> I would agree, but that's more because of the simplicity of interpreting
> the rules this way than that I'm any sort of rules expert....
> 
> > B) Suprisingly (to me at least) SpecialRights has to no location field,
> 
> thus I had
> 
> > to hardcode the coalfield hex location. On the other hand I did not know
> > what to do with fields rightValue and rightDefaultValue.
> 
> Ah, good point.
> I had created Rights as a map so it could be used for more complex cases,
> but the value is currently unused and remains null.
> Would it help to use the location name as the value of this right? Any
> other ideas?
> 
> In addition: would it be useful to give this hex (or HexStation) a special
> type once we have implemented that new concept?
> Here we could reuse type "mine", because that's a pretty generic type that
> occurs in several games.
> 
> > C) The finishConfiguration method of SpecialProperties for a
> > (Public)Company were not called. I added the missing call to the
> > finishConfiguration of PublicCompany. I have not checked if this call is
> 
> also
> 
> > missing for PrivateCompany and/or should be better moved up to the
> > Company class.
> 
> OK, I'll have a look.  Yesterday I had the same problem with Phase.
> 
> finishConfiguration() is intended to be generic in all configurable
> classes, but it's an afterthought and is so far only called where it is
> really used (and apparently not even that!).
> 
> > D) Personally I am not too happy that the main code parts of Rights
> > (which
> 
> in
> 
> > my view is not a very general part of 18xx) are  inside the main classes
> > PublicCompany and OperatingRound, which are already difficult to
> > understand and in my view have grown too large.
> 
> Well, right.  But otherwise specific OperatingRound_1830 and
> PublicCompany_1830 classes would be needed to implement this feature, and I
> found that a bit of overkill too.  But it's still an option. Would you have
> preferred that approach?  The SpecialRight class would then also become
> specific and be renamed to CoalfieldsRight or so.
> 
> I have no idea in what other games we could use Rights. As I have named it,
> it's very generic and could perhaps be employed in currently unexpected
> ways. But I must admit that I can't give any example, so maybe you're
> right.
> 
> > But breaking up the Round
> > classes has been on my agenda for long and I know that Erik is not happy
> > about that idea neither ;-)
> 
> That could be so because of my rusty brains, of course.  It's not so that I
> would run away if you started doing such things.  But I think that it will
> be (1) a hell of a lot of work, and (2) pretty dangerous.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- 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] Wiki: playing modes

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

I like that and will update the section on the use as Moderator.

On Friday, July 08, 2011 12:07:35 am Erik Vos wrote:
> I have created a new Wiki page called "Playing modes" to describe the
> various ways in which Rails can be used.
> 
> I mainly did this to fulfil my promise to describe the Autosave/load
> feature, but I have also added headings for other modes, with some text or
> just a placeholder. I hope that people better qualified than I am will
> enter or complete these other mode descriptions.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- 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

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

Brett,
so what is your suggestion exactly?

Mine was:
City (on the map, tokenable) => HexStation
Station (on tile only) => Station

I understood Erik's to be:
City => Stop
Station => Station

I can live with that, however for me it is now improvement compared to the 
previous solution.
But this still keeps Station.

Maybe your a merger of the two:
City => HexStop or MapStop
Station => Stop or TileStop

Stefan


On Thursday, July 07, 2011 06:49:53 pm brett lentz wrote:
> On Thu, Jul 7, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
> >> A. City vs. HexStation:
> > I find myself increasingly using the term "train stop".  So, what about
> > Stop or TrainStop?  Very descriptive, and (as you know) I love short
> > type names. Also Stop has no confusing connotations, as City and Station
> > have.
> > 
> > Erik.
> 
> +1 from me. I like "Stop" a bit better, too. It maps closer to the
> logical function of those features on the hex.
> 
> We can use "City" and "Station" as user-visible tags, if we want, but
> to keep the internal data organization sane, I'd like to deprecate
> those terms.
> 
> ---------------------------------------------------------------------------
> --- 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] Wiki: playing modes

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

I have created a new Wiki page called "Playing modes" to describe the
various ways in which Rails can be used.

I mainly did this to fulfil my promise to describe the Autosave/load
feature, but I have also added headings for other modes, with some text or
just a placeholder. I hope that people better qualified than I am will enter
or complete these other mode descriptions.  

Erik.

Re: [Rails-devel] Coalfields and states

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

So that makes two, but this one is sufficiently different to require a
special class anyway, so perhaps we should go that way for 1830 Coalfields
as well, as Stefan implies.

Erik.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: donderdag 7 juli 2011 16:22
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Coalfields and states

 

Here is the rules section on 1850's Mesabi Range.

 

6.5.1 The Mesabi Range

The Mesabi Range is a special grey hex. To run to or

through the Mesabi Range a company must pay the $80

cost for rights to the Mesabi Range. Paying for the Mesabi

Range counts as a yellow tile lay.

If the Mesabi Range private company has been closed, the

money for the Mesabi range goes to the bank. If a public

company owns the Mesabi Range private company, it receives

half of the Mesabi Range connecting money with

the rest going to the bank.

The rights to the Mesabi Range may not be purchased until

the Mesabi Range private company has been closed or

sold to a public company. As there are only four Mesabi

tokens, only four companies may have the rights to the

Mesabi.

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

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

On Thu, Jul 7, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:
>> A. City vs. HexStation:
>
> I find myself increasingly using the term "train stop".  So, what about Stop
> or TrainStop?  Very descriptive, and (as you know) I love short type names.
> Also Stop has no confusing connotations, as City and Station have.
>
> Erik.
>


+1 from me. I like "Stop" a bit better, too. It maps closer to the
logical function of those features on the hex.

We can use "City" and "Station" as user-visible tags, if we want, but
to keep the internal data organization sane, I'd like to deprecate
those terms.

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

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

> A. City vs. HexStation:

I find myself increasingly using the term "train stop".  So, what about Stop
or TrainStop?  Very descriptive, and (as you know) I love short type names.
Also Stop has no confusing connotations, as City and Station have.

Erik.
 

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

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

I had already included “medium” as a possible train stop type. 

Erik.

 

Van: Dr....@t-... [mailto:Dr....@t-...] 
Verzonden: donderdag 7 juli 2011 9:10
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Running to and through stations

 

HI Stefan & Eric,

 

in regard to the current development work by you guys, how do you envision to cover the medium city types from the O&O games ?

 

I.e. Stops that can either be developed into cities or stay as whistlestops ?

 

Regards,

Martin

 

-----Original-Nachricht-----
Subject: Re: [Rails-devel] Running to and through stations
Date: Thu, 07 Jul 2011 07:38:04 +0200
From: Stefan Frey <ste...@we...>
To: "Development list for Rails: an 18xx game" <rai...@li...>

Erik:
sorry for the late reply, but I wanted to have a look at the the current code 
base and my ideas first before my reply.

I have added support for the RunTo and RunThrough attributes in a provisional 
way, so Coalfields should work now.
Overall I think the current solution is working now and will cover for example 
the off-board areas of 18Scan. But in the longer run a refactoring would be 
helpful.
Stefan

My suggestions:

Actually I use a different ordering of my thoughts as my approach again would 
be still different, but hopefully not orthogonal.

A. City vs. HexStation:
Actually I got used to City and Station by now, but the main issue still is to 
explain that strongly. The best is that a City or HexStation exists for each 
city/station on the map, whereas there is only one Station per TileId. The 
major consequence is that token can only live on City/HexStation, but never on 
Stations.

B. List of attributes
I do not care so much about the precise attributes, as long as the 
suggestions/requirements below are considered. I can live with any of those 
you suggested below.

C. Station Types
Use the same pattern to define types as for trains and companies.
Example:
<StationType name="OffBoard" runThrough="no" runTo="yes" type="major" > 
<StationType name="City" runThrough="token" runTo="yes" type="major" > 
<StationType name="Town" runThrough="yes" runTo="yes" type="minor" > 

Allow modifications of inidividual attributes on the ajdustable TileSet.xml 
(Suggestion rename that to GameTiles.xml, I can never remember which one is 
the game specific one) and Map.xml, with Map.xml taking precedence.

D. Keep decision tree manageable
Keep in mind that the conditions to check should be not to difficult to 
evaluate.

The current code to decide if a station is a sink (cannot be run-through) is 
the following: (from NetworkVertex initRailsVertex)

// station is offboard area
if (station.getType().equals(Station.OFF_MAP_AREA) || (
// or station is city
station.getType().equals(Station.CITY)
// and is either fully tokened and has token slots or only 
tokens allow run through 
&& ( city.getSlots() != 0 && !city.hasTokenSlotsLeft() || 
hex.isRunThroughAllowed() == MapHex.Run.TOKENONLY)
// and city does not have a token
&& !city.hasTokenOf(company))
) {

So it is still manageable, but it should not get more complex. And replacing 
the hard-coded station-types by the new variable one suggested in C would make 
things easier on several places in the code base. However it will require 
identifying those cases.



On Friday, July 01, 2011 11:19:02 pm Erik Vos 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

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

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

Here is the rules section on 1850's Mesabi Range.

6.5.1 The Mesabi Range
The Mesabi Range is a special grey hex. To run to or
through the Mesabi Range a company must pay the $80
cost for rights to the Mesabi Range. Paying for the Mesabi
Range counts as a yellow tile lay.
If the Mesabi Range private company has been closed, the
money for the Mesabi range goes to the bank. If a public
company owns the Mesabi Range private company, it receives
half of the Mesabi Range connecting money with
the rest going to the bank.
The rights to the Mesabi Range may not be purchased until
the Mesabi Range private company has been closed or
sold to a public company. As there are only four Mesabi
tokens, only four companies may have the rights to the
Mesabi.

Re: [Rails-devel] Coalfields and states

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

On Thu, Jul 7, 2011 at 8:58 AM, Chris Shaffer <chr...@gm...>wrote:
>
> I have a memory of a game with a mine that requires purchase of the right
> to run through it.  I think it was the Mesabi Range, and if my memory is
> correct it's a grey tile in the  top middle of the board.
>

Sure.  That's 1850's Mesabi Range.

It works like the 1830 Coalfields rights purchasing, but the $80 payment
goes half to the owning company and half to the bank.  If it is closed, the
money goes to the bank. It also counts as the company's yellow tile lay.

Re: [Rails-devel] Coalfields and states

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

>
> I have no idea in what other games we could use Rights. As I have named it,
> it's very generic and could perhaps be employed in currently unexpected
> ways. But I must admit that I can't give any example, so maybe you're
> right.


I have a memory of a game with a mine that requires purchase of the right to
run through it.  I think it was the Mesabi Range, and if my memory is
correct it's a grey tile in the  top middle of the board.

--
Chris

Please consider the environment before printing this e-mail.

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

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> 
> A. City vs. HexStation:
> Actually I got used to City and Station by now, but the main issue still
is to
> explain that strongly. The best is that a City or HexStation exists for
each
> city/station on the map, whereas there is only one Station per TileId. The
> major consequence is that token can only live on City/HexStation, but
never
> on Stations.

Exactly. 
 
> B. List of attributes
> I do not care so much about the precise attributes, as long as the
> suggestions/requirements below are considered. I can live with any of
those
> you suggested below.
> 
> C. Station Types
> Use the same pattern to define types as for trains and companies.
> Example:
> <StationType name="OffBoard" runThrough="no" runTo="yes"
> type="major" > <StationType name="City" runThrough="token"
> runTo="yes"  type="major" > <StationType name="Town" runThrough="yes"
> runTo="yes"  type="minor" >

Yes, that is what we called the "defaults", right?

> Allow modifications of inidividual attributes on the ajdustable
TileSet.xml
> (Suggestion rename that to GameTiles.xml, I can never remember which one
> is the game specific one) and Map.xml, with Map.xml taking precedence.

GameTiles.xml  would be fine with me.

> D. Keep decision tree manageable
> Keep in mind that the conditions to check should be not to difficult to
> evaluate.
> 
> The current code to decide if a station is a sink (cannot be run-through)
is the
> following: (from NetworkVertex initRailsVertex)
> 
> 		// station is offboard area
> 	if (station.getType().equals(Station.OFF_MAP_AREA) || (
>                 // or station is city
>                 station.getType().equals(Station.CITY)
>                 // and is either fully tokened and has token slots or only
tokens allow
> run through
>                 && ( city.getSlots() != 0 && !city.hasTokenSlotsLeft() ||
> hex.isRunThroughAllowed() == MapHex.Run.TOKENONLY)
>                 // and city does not have a token
>                 && !city.hasTokenOf(company))
>                 ) {
> 
> So it is still manageable, but it should not get more complex. And
replacing
> the hard-coded station-types by the new variable one suggested in C would
> make things easier on several places in the code base. However it will
require
> identifying those cases.

Some complexity can't be avoided, but the intention is to keep it as simple
as possible indeed. I think you can best judge this aspect, and that why I'm
trying to define this whole thing as completely as possible before starting
to code.

In my view, HexStation would be responsible to collect all data about a
train stop, so that would be your main entry point.
However, these properties would also be directly obtainable from Tile and
Hex. You'll need that in some cases.

A few special cases that I have on my mind, and that are perhaps worth
thinking about already in this stage:

- 1860: loop="no" would apply to all tiles, also plain track, so there you
can't just use HexStation. Not sure how to configure this case.

- 18VA: I would use type="mine" for the CMDs, and type="minor" for the mines
(which look like, and in fact are, towns in all respects but the name).
This usage of type="mine" would be in line with e.g. 1837.

- Several games have "ports", but I believe in almost all cases these behave
exactly like towns, so I'm not sure we need that as a separate type. The
18VA ports are not separate train stops but bonuses for the nearby cities if
tokened, so I think these ports should be treated differently.

There is probably much more, but I have given up to keep up with all newest
games.

Erik.

Re: [Rails-devel] Coalfields and states

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

Thanks, Stefan.

> A) Reading the rules carefully it seems that the rights are only required
for
> the revenue train run, not for tracing a route for tile and token laying.
Do all
> agree on this?

I would agree, but that's more because of the simplicity of interpreting the
rules this way than that I'm any sort of rules expert....
 
> B) Suprisingly (to me at least) SpecialRights has to no location field,
thus I had
> to hardcode the coalfield hex location. On the other hand I did not know
> what to do with fields rightValue and rightDefaultValue.

Ah, good point. 
I had created Rights as a map so it could be used for more complex cases,
but the value is currently unused and remains null.
Would it help to use the location name as the value of this right? Any other
ideas?

In addition: would it be useful to give this hex (or HexStation) a special
type once we have implemented that new concept?
Here we could reuse type "mine", because that's a pretty generic type that
occurs in several games.

> C) The finishConfiguration method of SpecialProperties for a
> (Public)Company were not called. I added the missing call to the
> finishConfiguration of PublicCompany. I have not checked if this call is
also
> missing for PrivateCompany and/or should be better moved up to the
> Company class.

OK, I'll have a look.  Yesterday I had the same problem with Phase.

finishConfiguration() is intended to be generic in all configurable classes,
but it's an afterthought and is so far only called where it is really used
(and apparently not even that!).
 
> D) Personally I am not too happy that the main code parts of Rights (which
in
> my view is not a very general part of 18xx) are  inside the main classes
> PublicCompany and OperatingRound, which are already difficult to
> understand and in my view have grown too large.

Well, right.  But otherwise specific OperatingRound_1830 and
PublicCompany_1830 classes would be needed to implement this feature, and I
found that a bit of overkill too.  But it's still an option. Would you have
preferred that approach?  The SpecialRight class would then also become
specific and be renamed to CoalfieldsRight or so.

I have no idea in what other games we could use Rights. As I have named it,
it's very generic and could perhaps be employed in currently unexpected
ways. But I must admit that I can't give any example, so maybe you're right.

> But breaking up the Round
> classes has been on my agenda for long and I know that Erik is not happy
> about that idea neither ;-)

That could be so because of my rusty brains, of course.  It's not so that I
would run away if you started doing such things.  But I think that it will
be (1) a hell of a lot of work, and (2) pretty dangerous.

Erik.

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

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

HI Stefan & Eric, 

	in regard to the current development work by you guys, how do you
envision to cover the medium city types from the O&O games ? 

	I.e. Stops that can either be developed into cities or stay as
whistlestops ? 

	Regards, 

	Martin 

	-----Original-Nachricht-----
 Subject: Re: [Rails-devel] Running to and through stations
 Date: Thu, 07 Jul 2011 07:38:04 +0200
 From: Stefan Frey <ste...@we...>
 To: "Development list for Rails: an 18xx game"
<rai...@li...>

 Erik:
 sorry for the late reply, but I wanted to have a look at the the
current code 
 base and my ideas first before my reply.

 I have added support for the RunTo and RunThrough attributes in a
provisional 
 way, so Coalfields should work now.
 Overall I think the current solution is working now and will cover
for example 
 the off-board areas of 18Scan. But in the longer run a refactoring
would be 
 helpful.
 Stefan

 My suggestions:

 Actually I use a different ordering of my thoughts as my approach
again would 
 be still different, but hopefully not orthogonal.

 A. City vs. HexStation:
 Actually I got used to City and Station by now, but the main issue
still is to 
 explain that strongly. The best is that a City or HexStation exists
for each 
 city/station on the map, whereas there is only one Station per
TileId. The 
 major consequence is that token can only live on City/HexStation, but
never on 
 Stations.

 B. List of attributes
 I do not care so much about the precise attributes, as long as the 
 suggestions/requirements below are considered. I can live with any of
those 
 you suggested below.

 C. Station Types
 Use the same pattern to define types as for trains and companies.
 Example:
 <StationType name="OffBoard" runThrough="no" runTo="yes" 
type="major" > 
 <StationType name="City" runThrough="token" runTo="yes"  type="major"
> 
 <StationType name="Town" runThrough="yes" runTo="yes"  type="minor" >


 Allow modifications of inidividual attributes on the ajdustable
TileSet.xml 
 (Suggestion rename that to GameTiles.xml, I can never remember which
one is 
 the game specific one) and Map.xml, with Map.xml taking precedence.

 D. Keep decision tree manageable
 Keep in mind that the conditions to check should be not to difficult
to 
 evaluate.

 The current code to decide if a station is a sink (cannot be
run-through) is 
 the following: (from NetworkVertex initRailsVertex)

 // station is offboard area
 if (station.getType().equals(Station.OFF_MAP_AREA) || (
 // or station is city
 station.getType().equals(Station.CITY)
 // and is either fully tokened and has token slots or only 
 tokens allow run through 
 && ( city.getSlots() != 0 && !city.hasTokenSlotsLeft() || 
 hex.isRunThroughAllowed() == MapHex.Run.TOKENONLY)
 // and city does not have a token
 && !city.hasTokenOf(company))
 ) {

 So it is still manageable, but it should not get more complex. And
replacing 
 the hard-coded station-types by the new variable one suggested in C
would make 
 things easier on several places in the code base. However it will
require 
 identifying those cases.

 On Friday, July 01, 2011 11:19:02 pm Erik Vos 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

 ------------------------------------------------------------------------------
 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 have added the revenue support for the Coalfield rights.
This and the commit before should complete the support of Reading and 
Coalfield variants, am I right?

Several issues arose:

A) Reading the rules carefully it seems that the rights are only required for 
the revenue train run, not for tracing a route for tile and token laying. Do 
all agree on this?

SpecialRights accordingly implements the RevenueStaticModifier.

B) Suprisingly (to me at least) SpecialRights has to no location field, thus I 
had to hardcode the coalfield hex location. On the other hand I did not know 
what to do with fields rightValue and rightDefaultValue.

C) The finishConfiguration method of SpecialProperties for a (Public)Company 
were not called. I added the missing call to the finishConfiguration of 
PublicCompany. I have not checked if this call is also missing for 
PrivateCompany and/or should be better moved up to the Company class.

D) Personally I am not too happy that the main code parts of Rights (which in 
my view is not a very general part of 18xx) are  inside the main classes 
PublicCompany and OperatingRound, which are already difficult to understand 
and in my view have grown too large. But breaking up the Round classes has 
been on my agenda for long and I know that Erik is not happy about that idea 
neither ;-)

Stefan



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

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

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

Erik:
sorry for the late reply, but I wanted to have a look at the the current code 
base and my ideas first before my reply.

I have added support for the RunTo and RunThrough attributes in a provisional 
way, so Coalfields should work now.
Overall I think the current solution is working now and will cover for example 
the off-board areas of 18Scan. But in the longer run a refactoring would be 
helpful.
Stefan

My suggestions:

Actually I use a different ordering of my thoughts as my approach again would 
be still different, but hopefully not orthogonal.

A. City vs. HexStation:
Actually I got used to City and Station by now, but the main issue still is to 
explain that strongly. The best is that a City or HexStation exists for each 
city/station on the map, whereas there is only one Station per TileId. The 
major consequence is that token can only live on City/HexStation, but never on 
Stations.

B. List of attributes
I do not care so much about the precise attributes, as long as the 
suggestions/requirements below are considered. I can live with any of those 
you suggested below.

C. Station Types
Use the same pattern to define types as for trains and companies.
Example:
<StationType name="OffBoard" runThrough="no" runTo="yes"  type="major" > 
<StationType name="City" runThrough="token" runTo="yes"  type="major" > 
<StationType name="Town" runThrough="yes" runTo="yes"  type="minor" > 

Allow modifications of inidividual attributes on the ajdustable TileSet.xml 
(Suggestion rename that to GameTiles.xml, I can never remember which one is 
the game specific one) and Map.xml, with Map.xml taking precedence.

D. Keep decision tree manageable
Keep in mind that the conditions to check should be not to difficult to 
evaluate.

The current code to decide if a station is a sink (cannot be run-through) is 
the following: (from NetworkVertex initRailsVertex)

		// station is offboard area
	if (station.getType().equals(Station.OFF_MAP_AREA) || (
                // or station is city
                station.getType().equals(Station.CITY)
                // and is either fully tokened and has token slots or only 
tokens allow run through 
                && ( city.getSlots() != 0 && !city.hasTokenSlotsLeft() || 
hex.isRunThroughAllowed() == MapHex.Run.TOKENONLY)
                // and city does not have a token
                && !city.hasTokenOf(company))
                ) {

So it is still manageable, but it should not get more complex. And replacing 
the hard-coded station-types by the new variable one suggested in C would make 
things easier on several places in the code base. However it will require 
identifying those cases.



On Friday, July 01, 2011 11:19:02 pm Erik Vos 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

Re: [Rails-devel] Autosave/load revisited

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

Thanks for your feedback.  That's exactly what I need.

> * Popup appears under the active window (why?)

It shouldn't, and I can't remember seeing that happening.  I'm trying to get
the active window always on top, no clue why that doesn't work for you.

> * Not evident enough whose turn it is (would it be possible to change the
background color of the interface or something more noticeable like that
when it is my turn?

I have also been thinking about ways to make that better stand out, such as
displaying the current player name somewhere in a highlighted format (but
where?). 

> * I don't see the advantage of restricting player moves to the local
player. When we play a live game online, often one player executes several
SR actions when players are doing rote actions like floating new companies.

At least it shows who's turn it is....   

It shouldn't be too difficult to make this restriction optional, but then
the previous issue must be fixed first.  Also, *all* instances must then be
polling all the time, not just those that don't have the turn; not sure if
that couldn't cause clashes.

> * Any reason to restrict the polling interval to every 10 seconds?  Could
it be allowed to be done every second?

That's pretty often...   I suppose it could, but I don't know if file
contention couldn't become a problem then.

> * Why do the complex actions cause errors?  Is it because player input is
needed outside of the normal turns?  If any player could enter commands for
all players, would that fix it?

I'm not sure, but your suggestion could well be (part of) the problem. These
special actions are executed by special code, and I think not all of that
already follows the rules yet.

> For reference, I have played a few live games using Rails/Dropbox and it
already flows pretty smoothly without the Autosave feature.  We use voice
chat.  During the private auction and SRs, we typically have had one player
enter commands and the others tell him what to do.  Once we get to a complex
decision or an OR, we have that player save it and "transfer control" to the
active player.  This speeds things up quite a bit over what I would assume
the current version of Autosave/load.

> I think that removing the restriction on the active player would make this
feature into something I would use on a regular basis.

OK, thanks for your input. I'll consider it.

Erik.

Re: [Rails-devel] Autosave/load revisited

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

Thanks, Erik.  I Autosave/load a quick try.

A few comments:
* Popup appears under the active window (why?)
* Not evident enough whose turn it is (would it be possible to change the
background color of the interface or something more noticeable like that
when it is my turn?
* I don't see the advantage of restricting player moves to the local player.
When we play a live game online, often one player executes several SR
actions when players are doing rote actions like floating new companies.
* Any reason to restrict the polling interval to every 10 seconds?  Could it
be allowed to be done every second?
* Why do the complex actions cause errors?  Is it because player input is
needed outside of the normal turns?  If any player could enter commands for
all players, would that fix it?

For reference, I have played a few live games using Rails/Dropbox and it
already flows pretty smoothly without the Autosave feature.  We use voice
chat.  During the private auction and SRs, we typically have had one player
enter commands and the others tell him what to do.  Once we get to a complex
decision or an OR, we have that player save it and "transfer control" to the
active player.  This speeds things up quite a bit over what I would assume
the current version of Autosave/load.

I think that removing the restriction on the active player would make this
feature into something I would use on a regular basis.

FYI, we managed to play a game of 18GA in about 2.5 hours, which is about a
half hour faster than my experiences using the physical components.

[Rails-devel] Autosave/load revisited

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

Scott,

 

To test Autosave/load you can run several Rails copies in parallel by
specifying a different local user name for each process, with the
command-line argument 

-Dlocal.player.name=<nameOfPlayer>

If you want to keep the logs separate, you should add something like

                -Dlog4j.configuration=<path>/<nameOfPlayer>.properties

 

For each player, you start with loading the same initial saved file, and
then go to File|Autosave/load immediately.  A popup is displayed, in which
you must select "On".  You can also change the polling interval to your
liking (default 30 sec.).  Press "OK". 

At the start of a game, let the first player do this first. Pressing "OK"
automatically creates an initial saved file, which then must be loaded by
the other players.  Still, all players must use the menu and select "On".

 

I copy the description below from an earlier email.  I'll see if I can put
this in the wiki.  

 

Please note, that this whole thing is still experimental.  Several
improvements are already foreseen, and it is known to break down on complex
activities like the 1856 CGR formation or the 18EU Final Minor Exchange
Round.  So better try it with some simpler games first.

 

Erik

 

<Copied from an old post>

 

1. Autosave/load is activated by checking a menu option. Steps 2 and 3 apply
only if this option has been activated.

 

2. Every time that an active player loses the turn, the following is done:

2a. A saved file is written to the default location (the first time the
usual popup will ask for it) and with the usual filename:

<prefix>_<timestamp>_<player>.rails.

2b. The name of this file is written into another (new) file, named
<prefix>.last_rails.

2c. Rails goes into polling mode. (Ideally, all actions should be prohibited
except Quit and perhaps some more).

 

3. In polling mode, Rails regularly reads the .last_rails file to check if
the filename has changed. The interval is configurable (default 30 secs?).

If a new filename is found:

3a. This file is read and processed in the same way as Reload does it.

3b. Rails checks if the player has got the turn. If so, polling mode is
suspended, and normal operation resumes. Otherwise, polling mode continues.

 

4. When Rails is restarted for an ongoing game, the last saved file must be
loaded manually. Autosave/load can only be activated after that. If the
local player does not have the turn, Rails will enter polling mode at that
point.

 

Notes:

1. Normally, each game should use a separate directory.  In theory it should
be possible to run multiple games in one directory, if each game is given a
unique <prefix> at the *first* save action, but this is not recommended.

2. Repeated reloading during polling mode ensures that actions by other
players show up with a reasonable delay.

3. It does not matter if a saved file is missed because the interval is
longer than the time between two saves by other players. Each saved file
contains the whole game history.

 

 

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: woensdag 6 juli 2011 15:50
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Refactored loading code

 

On Wed, Jul 6, 2011 at 4:04 AM, Erik Vos <eri...@xs...> wrote:

But, as I have not got any feedback yet on this new feature, its further
development doesn't have a high priority for me right now.

 

Erik, I never figured out how Autosave/load is supposed to work.  What steps
would I do to test it?

 

I assume I could have two instances of Rails running on the same machine to
try it.

[Rails-devel] autosave/load testing, was: Refactored loading code

[Rick W. <wes...@pu...>]

----- Original Message -----
> On Wed, Jul 6, 2011 at 4:04 AM, Erik Vos < eri...@xs... > wrote:
> 
> 
> But, as I have not got any feedback yet on this new feature, its
> further
> development doesn't have a high priority for me right now.
> 
> 
> Erik, I never figured out how Autosave/load is supposed to work. What
> steps would I do to test it?
> 
> 
> I assume I could have two instances of Rails running on the same
> machine to try it.

   Even better would be to have two machines.  I tried this early on but have since run out of time to do more testing.   On the other hand I do appreciate Erik keeping this code around.  I suspect that it will be useful.

-- Rick

Re: [Rails-devel] Refactored loading code

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

I've been pulling the XML-related bits over into rails.common.parser.

I think that if there are more than 3-5 classes for a common purpose,
they can probably be organized into a sub-package.

---Brett.



On Wed, Jul 6, 2011 at 2:53 AM, Erik Vos <eri...@xs...> wrote:
> This makes me raise another question that has been on my mind for a long
> time: should we partially refactor the rails.game package into smaller
> subpackages?
> Examples: rails.game.round for all Round (sub)classes, rails.game.train,
> rails.game.map (hexes and tiles), perhaps others.
>
> I don't have strong feelings about it, it's just that rails.game is growing
> a bit largish.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: dinsdag 5 juli 2011 19:39
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] Refactored loading code
>>
>> That looks good to me.
>>
>> My overall goal with my refactoring is to remove the need for the
> rails.game
>> package to know about lower-level details, such as XML parsing.
>>
>> Moving the classes that need to know about how to load/save game files
>> outside of rails.game.* aligns very well with this goal. :-)
>>
>> ---Brett.
>>
>>
>>
>> On Tue, Jul 5, 2011 at 10:11 AM, Stefan Frey <ste...@we...> wrote:
>> > Brett & Erik,
>> > some time ago I started to refactor the game loading code in one class
>> > to get the ListAndFixSavedFiles utility adjusted to the new comments.
>> >
>> > To avoid more incompatibilities from the started refactoring from
>> > Brett now I thought to adjust the code to include the new reload
>> > functionality of Erik to be able to commit those changes.
>> >
>> > Nearly all loading functionality has been moved to a new GameLoader
>> > class in rails.util package. The load function in Game, GameManager
>> > and ListAndFixSavedFiles now all make use of a a GameLoader object.
>> >
>> > I have also added a line to the reload error message that asks the
>> > user to submit the corrupt save file to the Rails user list for bug
>> > tracking. If you think that is not a good idea, simply remove that
>> > text from LocalisedProperties.
>> >
>> > Stefan
>> >
>>
>>
> ----------------------------------------------------------------------------
> --
>> 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] Refactored loading code

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

On Wed, Jul 6, 2011 at 4:04 AM, Erik Vos <eri...@xs...> wrote:

> But, as I have not got any feedback yet on this new feature, its further
> development doesn't have a high priority for me right now.


Erik, I never figured out how Autosave/load is supposed to work.  What steps
would I do to test it?

I assume I could have two instances of Rails running on the same machine to
try it.