Re: [Rails-devel] HomeCityNumber (city attribute)

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

Hi Stefan,

The HexMap stop (city) number is a separate entity from the tile city
number. 
Initially, it is derived from the city numbers of the first tile laid, or
the preprinted tile if it already has tracks.
When tiles are upgraded, the HexMap city numbers normally do not change; the
HexMap stops become related to the new tile cities, in a way that existing
tracks remain connected to a HexMap stop with the same number.
This means, that after an upgrade the HexMap city numbers may become
different from the current tile city numbers. The current tile city numbers
have no meaning for game play.

If the old tile had no tracks, there is nothing to preserve, so the new tile
city numbers are just copied. Any home token stops on such tiles have city
number 0, which indicates that these must be assigned manually as soon as a
tile with some track is laid (Erie, THB, Badische).

If during an upgrade the number of stops on a tile changes, HexMap stop
numbers are reassigned, although (I believe) it is attempted to retain the
old numbers where possible.

This all is complex stuff indeed. It took me a lot of time and false starts
to get this reasonably working, and it is quite possible that cases exist
that do not work out well.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, September 05, 2012 1:57 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] HomeCityNumber (city attribute)
> 
> Erik,
> is it intentional that the HomeCityNumber refers to the position inside
the list
> of Stops of HexMap?
> 
> I refer to the following code in method layHome of mapHex:
> 
>                  Stop homeCity = stops.get(Math.max(stopNumber - 1, 0));
>                  homes.put(company, homeCity);
> 
> I thought that mStops.get(...) instead of stops.get(...) would have been
the
> more logical choice as mStops maps the stations/stops ids to the objects.
> 
> Usually if Rails refer to Stations it is the number defined by position on
the
> tile and not the order number.
> 
> This caught me by surprise yesterday and took quite some time to track
> down.
> 
> This has a strong influence on the definition of the city attribute of the
Home
> tag: Instead of the specification of the station position, it refers to
the
> ordering of stations inside the Tile definition.
> However in the full loop it makes some sense, as in the Tile definition
the
> stations have ids, that are identical with the ordering of the
definitions.
> 
> But those ids are not used to set up the station numbers, those are based
on
> the position on the tile.
> 
> As you are the expert of Tile and Map definitions, I want to ask you for
your
> opinion: Is there more behind it or is it something we should fix in the
longer
> run at least (and could add some comments in the code/configuration for
this
> behavior)?
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel