Re: [Rails-devel] 1825 patch

[Phil D. <de...@gm...>]

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.

I'll look into this

> And I would prefer if everything related to the formationOrderIndex is kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.

There was a reason I had to put it in the interface, although this is
probably largely due to a lack of coding skill on my part...

Oh yeah, in OperatingRound_1825, line 23:

for (PublicCompanyI company : companyManager.getAllPublicCompanies()) {

If you make that foreach loop PublicCompany_125 then
getAllPublicCompanies doesn't work because that returns a collections
of PublicCompanyI objects.  There is likely a better way to fix this
than putting that information into the interface class so if so I'm
happy to be corrected!


>> Route awareness and revenue calculation: Have a variety of issues.
>> I'm reasonably confident I can fix these with the framework Stefan has
>> put together, I just haven't got round to looking at what needs doing
>> yet, so for the moment these two settings default to off.
>>
> Actually I only read your mail carefully after I have added the required code
> for 1825 revenue calculation. Sorry for not leaving that for you.
> A good reason for that was that I had the idea for the 1825 issues already in
> mind during the implementation of the revenue modifier framework.
> And from this I knew that I had to change a few subtle issues there to allow
> the 1825 modifiers show the results correctly.
> Without those the task would have been much harder.
>
> So there are now two dynamic modifiers, which allow double heading and prevent
> termination at towns. Feel free to test and adapt them to your needs.

I need to look in general how the modifiers for route calculation
work, I have a lot of saved emails to trawl through when I get the
spare time :)

> There is still one issue on revenue calculation: There is nothing preventing a
> train visiting two stations on a tile. The current method is to set the city
> attribute for all station of that tile to an identical value (in Tiles.xml).
> Erik already critized that and I am close to suggest that an attribute in
> TileSet.xml might be better (for example a VisitOnlyOnce attribute).
>
> Route awareness is currently work in progress, as I intend to add true route
> checks in a hopefully not too distant future. As 1825 has some rule
> adjustments in that area, it is worth to wait for changes there. I intend to
> provide a modifier interface similar to those used for revenue calculation.
>