Menu
▾
▴
Re: [Rails-devel] Running to and through stations
|
From: Erik V. <eri...@xs...> - 2011-07-01 23:13:35
|
Please read 1851 for 18AL.
> -----Oorspronkelijk bericht-----
> Van: Erik Vos [mailto:eri...@xs...]
> Verzonden: vrijdag 1 juli 2011 23:19
> Aan: 'Development list for Rails: an 18xx game'
> Onderwerp: [Rails-devel] Running to and through stations
>
> Stefan (& others):
>
> I'm having another look at the station properties that we have discussed a
> while ago.
>
> Let's first state what my approach would probably be.
>
> 1. The City class will be renamed to HexStation, because that describes
best
> what it is: the relationship between a Station (a potential train stop on
a tile)
> and a Hex (where a tile with such a Station has been laid upon).
> It is this relationship that defines an actual train stop.
>
> 2. The HexStation objects will provide you the station properties to be
> discussed below.
>
> 3. The station properties can be defined in either MapHex (<Hex> in
> Map.xml) or in Tile (<Tile> in TileSet.xml), or both; in the last case,
<Hex>
> takes precedence, as it is more specific.
>
> 4. In both places I propose to define these properties as a subtag
<Access>
> that has attributes that define the station properties. If necessary, a
> restriction could be added to one station on a multi-station tile, but I'm
not
> aware of any cases where we would need that (perhaps 1841 Venezia, but I
> think defaults would apply there).
>
> 5. Hex defaults can be defined per hex type (colour) in Map.xml and Tile
> defaults can be defined per tile station type (town, city) in TileSet.xml.
>
> Now the question arises what attributes and values we need. Your approach
> was a bit different from mine - in fact part of it is exactly orthogonal
to mine.
>
> In a different thread I had already proposed the following two attributes:
>
> - runTo={no|yes|tokenOnly}. "no" would apply to e.g. Birmingham in 18AL
> before phase 4 and Elsaß-Lothringen in 1835 except in phase 2. "tokenOnly"
> would apply to the 18Scan red cities. The "no" examples imply that this
> property should be settable as a result of phase changes. Would that be
> helpful?
>
> - runThrough={no|yes|tokenOnly}. "no" would apply to e.g. standard off-
> map areas, "tokenOnly" would apply to 1830 Altoona (PRR base). Your values
> "RunThrough" and "NoAccess" for closedStationAllows suggest that I should
> also add "always" (or "evenIfClosed") and "notIfClosed", but do we really
> need these values? Where?
>
> I would think that runTo and runThrough would better describe the kind of
> conditions that you would be looking for when you are constructing routes,
> than the openStationAllows and closedStationAllows attributes that you
> propose, but of course I may be wrong. It's really up to you.
>
> Not mentioned by me before, but inspired by your proposal:
>
> - loop={yes|no}. This defines whether one train may visit a hex/tile more
> than once. This would replace your station naming proposal. I think this
is
> simpler.
>
> - type={major|minor|medium} as you propose, except that I have added
> medium, which appears in some games. IMO this station type would be
> train-independent; train-specific usage of station types is to be defined
per
> train type. It could be useful in some cases where the tile looks like a
town,
> or is internally defined as a town (such as most off-map areas), but is
actually
> a non-tokenable city.
>
>
> Finally two questions about your proposal:
>
> 1. Is there any semantic difference between runFrom and runTo? To me,
> these words describe exactly the same aspects, at least in the 18xx
universe,
> where trains run directionless (perhaps I should say that "to" and "from"
> are quantum-superimposed?).
>
> 2. Do we really need N/A? Id 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
|
