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

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

Erik:
thanks for your reply. Unfortunately I cannot spare you the questions, 
as the TileMove is the last of the old Move-Classes to replace by the 
standard undo mechanism. And this involves looking into the 
MapHex/Station/Stop/Tile classes.

First sorry that I was partly wrong in my initial mail:

The station number is in fact derived from the id-tag in Tiles.xml, and 
not from the position-number, double-checked that again: It is true that 
the city attribute of the home tag of a company refers to the station 
number and the station number is the integer after "city" in the 
id-attribute:

Example:

<Tile colour="brown" id="66" name="66">
		<Station id="city1" position="002" slots="1" type="City" value="50"/>
		<Station id="city2" position="452" slots="1" type="City" value="50"/>
	
However the whole mechanism was not undo-proof:

In MapHex:
Both the list stops and the map mStops were not realized with state 
variables. Most likely they were still protected by the Tile-Move, but I 
have not double-checked this.

In Stop:
The related station itself is a GenericState. But all other variables 
(like slots, trackEdges and the access Attributes) are initialized once 
after the station changes. This is not undo proof, and this implies e.g. 
that the number of slots is not protected.

I have removed the duplication of stops and mStops in MapHex and made 
the attributes in stop undo-proof (or simply replaced a local variable 
by a call to the station attribute).
The access attributes have still to be fixed, but this relates to the 
next mail.

Stefan


On 09/05/2012 03:31 PM, Erik Vos wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>