Menu
▾
▴
Re: [Rails-devel] Running to and through stations
|
From: <Dr....@t-...> - 2011-07-07 07:10:40
|
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 |
