rails-devel

Re: [Rails-devel] [Rails-users] 1880 Foreign Investor bug (v.1.8.2)

[Martin B. <dr....@t-...>]

Hi Antero,

your last point most likely will be the explanation. But i'll check. The
rails revenue calculation code has not really been updated for 1880. Its
a complex piece of code. So we most likely will have to wait for its
creator to adapt that. Until that happens, player will have to check the
calculation themselves and take the revenue displayed as a guidance only.

Regards
Martin

On 28.10.2013 20:42, Antero Kuusi wrote:
> Actually, looking at the move file, the error seems to be something else
> and not of wrong train being used. Foreign Investor 6 had ran correctly
> before that move and it does say that Foreign Investor 7 has a 2+2 train to
> use. However, it still doesn't count the small station to the north of the
> starting location by default. Perhaps some trouble with ending the run in a
> small station and/or the fact that the hex had a medium station originally?
> 
> 
> 2013/10/28 Antero Kuusi <ak...@ik...>
> 
>> Here's a save file examples of the situation just before (Ville) and just
>> after (Atte) the move.
>>
>> Antero
>>
>>
>> 2013/10/28 Martin Brumm <dr....@t-...>
>>
>>> Am 28.10.2013 14:37, schrieb Antero Kuusi:
>>>> We noticed that the train selection for foreign investors does not
>>>> work correctly in all of the situations. Specifically, when the last
>>>> 2T has been bought, but the first 2+2T has not yet been bought, Rails
>>>> uses 2Ts for the foreign investors.
>>>>
>>>> The correct thing would be to use next available train, ie. 2+2T in
>>>> that situation, but without causing a phase change.
>>>>
>>>> We have not tested with the other type changes, but I assume it is the
>>>> same.
>>>>
>>>
>>> HI Antero,
>>> do you guys have a save file available that you could send to me ?
>>>
>>>
>>>
>>
> 

[Rails-devel] City to Town downgrade in revenue calculation (was: 1880 Foreign Investor bug (v.1.8.2))

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

Martin:
this issue is not surprising: It relates to the fact that the attributes 
of stop are set static at creation time in Rails 1.x.
This is changed in Rails 2.0 already (see below).

To remind anyone:
Station is an object that refers to the station on the tile.
As there is only one object per tile type (even if the game includes 
several copies of the tile), it cannot be used to store tokens.

Stop is an object that refers to the station on the mapHex. This allows
storing of the tokens. Stops usually (NOT always) survive a tile lay.

The attributes of a stop are assigned at the creation of the stop. What 
you can do is change the attributes from setRelatedStation at the time 
of tile lay. However to make this undo-proof all attributes have to
be state variables, unless the stop is not set to the previous 
attributes after a call to undo.

In Rails2.0 (compare branch route) this is changed already: Stops only 
store tokens and a reference to the station (dynamic) and mapHex 
(static, parent of stop), no other variables that can change. The 
attributes are always determined at run-time, so there is no need for 
state variables. Thus there will be no issue there.

In 1856 downgrades should work in general, as it implies removing the
stop. Upgrades could in principle be an issue, however there are
only standard trains in 1856, so the difference between towns and cities 
is not relevant for revenue calculation.

Stefan

PS: Could we please keep discussing development issues on the 
development list? This makes it easier to search for relevant 
discussions later. Thanks!


On 10/29/2013 10:34 PM, Martin Brumm wrote:
> Hi Stefan, Michael, Erik,
>
> upon the placement of a tile with a town onto the new tiles (in 1880)
> "Medium" Cities rails so far didnt change the initial type (as we didnt
> introduce this special type in the codebase). So its an 1880 problem.
>
> The quick fix was to alter setRelatedStation in Stop.java to change the
> Type and ScoreType to a town also.
>
> The more complex way might be to alter MapHex and Stop to incorporate
> the medium city type. But since that "downgrade" to town is the only
> option beside from that station staying as a city tile....
>
> But as usual the fix is only in the 1880 release branch yet, we might
> however fix that in a different way in 2.0 ?
>
> On another thought, isnt there another game where you can alter a town
> hex to a non town tile ?
>
> Kind Regards,
> Martin
>
>
>

Re: [Rails-devel] [Rails-users] 1880 Foreign Investor bug (v.1.8.2)

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

Martin,
if you give me a list of the open issues for revenue calculation in 1880 
and send me save files for those occasions, I will fix those.

However I thought Michael already addressed 1880 specifics of
revenue calculation?

And please tell me which of the branches is used for latest developments 
of 1880, for me to start with.

Stefan


On 10/28/2013 08:58 PM, Martin Brumm wrote:
> Hi Antero,
>
> your last point most likely will be the explanation. But i'll check. The
> rails revenue calculation code has not really been updated for 1880. Its
> a complex piece of code. So we most likely will have to wait for its
> creator to adapt that. Until that happens, player will have to check the
> calculation themselves and take the revenue displayed as a guidance only.
>
> Regards
> Martin
>
> On 28.10.2013 20:42, Antero Kuusi wrote:
>> Actually, looking at the move file, the error seems to be something else
>> and not of wrong train being used. Foreign Investor 6 had ran correctly
>> before that move and it does say that Foreign Investor 7 has a 2+2 train to
>> use. However, it still doesn't count the small station to the north of the
>> starting location by default. Perhaps some trouble with ending the run in a
>> small station and/or the fact that the hex had a medium station originally?
>>
>>
>> 2013/10/28 Antero Kuusi <ak...@ik...>
>>
>>> Here's a save file examples of the situation just before (Ville) and just
>>> after (Atte) the move.
>>>
>>> Antero
>>>
>>>
>>> 2013/10/28 Martin Brumm <dr....@t-...>
>>>
>>>> Am 28.10.2013 14:37, schrieb Antero Kuusi:
>>>>> We noticed that the train selection for foreign investors does not
>>>>> work correctly in all of the situations. Specifically, when the last
>>>>> 2T has been bought, but the first 2+2T has not yet been bought, Rails
>>>>> uses 2Ts for the foreign investors.
>>>>>
>>>>> The correct thing would be to use next available train, ie. 2+2T in
>>>>> that situation, but without causing a phase change.
>>>>>
>>>>> We have not tested with the other type changes, but I assume it is the
>>>>> same.
>>>>>
>>>>
>>>> HI Antero,
>>>> do you guys have a save file available that you could send to me ?
>>>>
>>>>
>>>>
>>>
>>
>
>
>