rails-devel — List for discussion of Rails development

Re: [Rails-devel] Implementation details for revenue calculation

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

Phil:
in my area (routing and revenue calculation) 1856 is the game I hardly tested. 
If I am not wrong, it has no unique features, thus everything should work 
fine, but that is a "should", thus tests would be very welcome there.
1835 should work ok in that respect.
Stefan


On Tuesday 25 May 2010 09:02:30 Phil Davies wrote:
> I'll probably be starting another game from source this week to test
> the impact on other games, is '35 at the stage where it would be
> worthwhile getting some testing feedback?  I was thinking of trying
> that out on my regulars.
>
> On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
> > 18EU Bankruptcy now seems to work correctly, and is open for testing for
> > whoever is interested in this feature and can compile from the sources.
> > In particular, more testing is needed for side effects on other games, as
> > the processes of starting and closing companies has changed somewhat. The
> > visibility of companies in GameStatus and ORPanel was the last main
> > issue.
> >
> > Undo is getting better, but doesn't yet seem work completely.
> >
> > More later this week.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday 24 May 2010 10:00
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Implementation details for revenue calculation
> >
> > Erik & Brett,
> > currently quite occupied with other tasks I am only adding small bits in
> > an incremental way. I think 1.3.0 is appropriate with a new game
> > supported and the first step to revenue and route support.
> >
> > I have added the support (or better removal) of the Birmingham tile
> > before phase 4 by defining an according NetworkGraphModifier interface,
> > which allows
> > to adjust the network graph immediately after creation. Changes defined
> > by this interface also effect the highlighting for tile and token lays.
> >
> > This implies that all titles should be supported, but I am sure there is
> > still
> > something is missing, especially for those games which I only know from
> > the rulebook.
> >
> > The fix of the 18EU bankruptcy should allow to close the bug 2954661.
> > Game End undos are already possible (I fixed that in 1.2).
> > Do you think it will be possible to provide an undo possibility for the
> > bankruptcy in 18EU as well?
> >
> > Stefan
> >
> > On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> >> Next weekend sounds good. In view of all the great stuff added by
> >> Stefan,
> >
> > a
> >
> >> minor release (1.3.0) might be appropriate?
> >>
> >> By now the bugs list is pretty empty; in the past few weeks I have fixed
> >> quite a lot.
> >>
> >> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
> >
> > get
> >
> >> that done this weekend, but I'm currently much distracted by other
> >> activities, so progress is slow. Right now, 18EU hangs in case of a
> >> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> >> bankruptcies are rare in 18EU.
> >>
> >> I have added comments to the 1835 description on a few remaining issues,
> >> with workarounds, but otherwise I think it's about done. I have marked
> >
> > 1835
> >
> >> "almost playable".
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: brett lentz [mailto:bre...@gm...]
> >> Sent: Friday 21 May 2010 18:55
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Implementation details for revenue
> >> calculation
> >>
> >> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> >> > Again some more update:
> >> >
> >> > Full support for 18AL and 18EU is in, 1851 has only Birmingham
> >> > missing. More details see below.
> >> >
> >> > As Brett and Erik keep quiet about their preference for a release
> >> > soon,
> >
> > I
> >
> >> kept
> >>
> >> > adding functionality.
> >>
> >> Excellent work.
> >>
> >> As for when to do a new release, a lot of it is down to how stable
> >> your changes are.  It sounds like we may be nearing a point where we
> >> are ready for a new release.
> >>
> >> How does next weekend sound?
> >>
> >> ---Brett.
> >
> > -------------------------------------------------------------------------
> >--
> >
> >>- --
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >--
> >
> >>---
> >>
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >--- --
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

I'll probably be starting another game from source this week to test
the impact on other games, is '35 at the stage where it would be
worthwhile getting some testing feedback?  I was thinking of trying
that out on my regulars.

On 24 May 2010 12:48, Erik Vos <eri...@xs...> wrote:
> 18EU Bankruptcy now seems to work correctly, and is open for testing for
> whoever is interested in this feature and can compile from the sources. In
> particular, more testing is needed for side effects on other games, as the
> processes of starting and closing companies has changed somewhat. The
> visibility of companies in GameStatus and ORPanel was the last main issue.
>
> Undo is getting better, but doesn't yet seem work completely.
>
> More later this week.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday 24 May 2010 10:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> Erik & Brett,
> currently quite occupied with other tasks I am only adding small bits in an
> incremental way. I think 1.3.0 is appropriate with a new game supported and
> the first step to revenue and route support.
>
> I have added the support (or better removal) of the Birmingham tile before
> phase 4 by defining an according NetworkGraphModifier interface, which
> allows
> to adjust the network graph immediately after creation. Changes defined by
> this interface also effect the highlighting for tile and token lays.
>
> This implies that all titles should be supported, but I am sure there is
> still
> something is missing, especially for those games which I only know from the
> rulebook.
>
> The fix of the 18EU bankruptcy should allow to close the bug 2954661.
> Game End undos are already possible (I fixed that in 1.2).
> Do you think it will be possible to provide an undo possibility for the
> bankruptcy in 18EU as well?
>
> Stefan
>
>
> On Friday 21 May 2010 22:10:41 Erik Vos wrote:
>> Next weekend sounds good. In view of all the great stuff added by Stefan,
> a
>> minor release (1.3.0) might be appropriate?
>>
>> By now the bugs list is pretty empty; in the past few weeks I have fixed
>> quite a lot.
>>
>> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
> get
>> that done this weekend, but I'm currently much distracted by other
>> activities, so progress is slow. Right now, 18EU hangs in case of a
>> bankruptcy, but I would't consider that a show-stopper; to my knowledge
>> bankruptcies are rare in 18EU.
>>
>> I have added comments to the 1835 description on a few remaining issues,
>> with workarounds, but otherwise I think it's about done. I have marked
> 1835
>> "almost playable".
>>
>> Erik.
>>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Friday 21 May 2010 18:55
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>>
>> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
>> > Again some more update:
>> >
>> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
>> > More details see below.
>> >
>> > As Brett and Erik keep quiet about their preference for a release soon,
> I
>>
>> kept
>>
>> > adding functionality.
>>
>> Excellent work.
>>
>> As for when to do a new release, a lot of it is down to how stable
>> your changes are.  It sounds like we may be nearing a point where we
>> are ready for a new release.
>>
>> How does next weekend sound?
>>
>> ---Brett.
>>
>>
> ---------------------------------------------------------------------------
>>- --
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ---------------------------------------------------------------------------
>>---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Hi Stefan,

On Mon, 24 May 2010 15:50:14 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Hi Alex,
> answers/comments see below.
> Most of them delay a more detailed discussion for the time after the  
> current
> release.
> Stefan
>
>> Oh, I see. That essentially means that you're using stack as a way to
>> dynamically allocate memory. It probably means that function inlining is
>> not working and the actual overhead may show up as a function call
>> overhead. Anyway, that's something to look at in the profiler. I was
>> hoping you've found some algorithm that was avoiding the need for  
>> dynamic
>> memory management.
>>
>
> In principle I could replace the reliance on the java stack mechanism by
> storing the local variables in own stack. The next step would be to  
> remove
> all recursive function calls, but I have doubts that this will improve  
> the
> speed substantially, if at all. I plan to install the TPFP plugin after  
> this
> release to get some data on that.
It certainly worth profiling before trying to change those things. Results  
may also differ depending on particular brand of JVM one is running...

>
>> > The scenarios where it excels compared to revenue predictions are  
>> those
>> > in
>> > which you cannot run the trains to the full length.
>>
>> I am not sure about that... If the optimal route set is achieved on 4+5
>> routes, it wouldn't matter which one is served by 8 train and which one  
>> is
>> by 10. I think it would only make difference on such scenarios where the
>> optimal route sets contains routes that have length between the length  
>> of
>> the trains (for example 6+9 routes for 8+10 trains).
>>
>
> I was more referring that the revenue prediction improves with the train  
> run
> lengths in general, not that train dominance is better in those cases.
I agree with that.

> The good thing about revenue prediction is that if the network increases  
> it
> gets less likely that the trains runs are short. It is very unlikely for  
> a
> company to have a complex network AND not being able to run its trains  
> for a
> good length.
You haven't seen some of our local games ;-)
But in general it depends on the game, I think. Typical scenario when such  
things happen is when there's a single choke-point with 2-3 exits. This  
means that the train that passes through it effectively bisects the graph  
into to for the remaining trains. I had some ideas about dealing with such  
cases - looking at the graph and finding vertices such that removal of 2  
adjacent to them splits the graph. In this situation optimization over 2  
(or more) parts can be done somewhat independently.

Alex.

Re: [Rails-devel] Improved revenue prediction / different scenario

[Stefan F. (web.de) <ste...@we...>]

Hi Alex,
answers/comments see below.
Most of them delay a more detailed discussion for the time after the current 
release.
Stefan

> Oh, I see. That essentially means that you're using stack as a way to
> dynamically allocate memory. It probably means that function inlining is
> not working and the actual overhead may show up as a function call
> overhead. Anyway, that's something to look at in the profiler. I was
> hoping you've found some algorithm that was avoiding the need for dynamic
> memory management.
>

In principle I could replace the reliance on the java stack mechanism by 
storing the local variables in own stack. The next step would be to remove 
all recursive function calls, but I have doubts that this will improve the 
speed substantially, if at all. I plan to install the TPFP plugin after this 
release to get some data on that.

> > The scenarios where it excels compared to revenue predictions are those
> > in
> > which you cannot run the trains to the full length.
>
> I am not sure about that... If the optimal route set is achieved on 4+5
> routes, it wouldn't matter which one is served by 8 train and which one is
> by 10. I think it would only make difference on such scenarios where the
> optimal route sets contains routes that have length between the length of
> the trains (for example 6+9 routes for 8+10 trains).
>

I was more referring that the revenue prediction improves with the train run 
lengths in general, not that train dominance is better in those cases.

The good thing about revenue prediction is that if the network increases it 
gets less likely that the trains runs are short. It is very unlikely for a 
company to have a complex network AND not being able to run its trains for a 
good length.

>
> No :-) But I can't find anything missing in my implementation. I wonder if
> we either misunderstand what each other counts or someones counting is
> wrong (though mine matching function call count shown by the profiler :) )

For the next release I plan to include the two-phase approach, this should 
ease comparisons.
>
>
> Alex.
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

18EU Bankruptcy now seems to work correctly, and is open for testing for
whoever is interested in this feature and can compile from the sources. In
particular, more testing is needed for side effects on other games, as the
processes of starting and closing companies has changed somewhat. The
visibility of companies in GameStatus and ORPanel was the last main issue.

Undo is getting better, but doesn't yet seem work completely. 

More later this week.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 24 May 2010 10:00
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Erik & Brett,
currently quite occupied with other tasks I am only adding small bits in an 
incremental way. I think 1.3.0 is appropriate with a new game supported and 
the first step to revenue and route support.

I have added the support (or better removal) of the Birmingham tile before 
phase 4 by defining an according NetworkGraphModifier interface, which
allows 
to adjust the network graph immediately after creation. Changes defined by 
this interface also effect the highlighting for tile and token lays. 

This implies that all titles should be supported, but I am sure there is
still 
something is missing, especially for those games which I only know from the 
rulebook.

The fix of the 18EU bankruptcy should allow to close the bug 2954661. 
Game End undos are already possible (I fixed that in 1.2).
Do you think it will be possible to provide an undo possibility for the 
bankruptcy in 18EU as well?

Stefan


On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> Next weekend sounds good. In view of all the great stuff added by Stefan,
a
> minor release (1.3.0) might be appropriate?
>
> By now the bugs list is pretty empty; in the past few weeks I have fixed
> quite a lot.
>
> I'm working on the 18EU bankruptcy rules, which were missing. I hope to
get
> that done this weekend, but I'm currently much distracted by other
> activities, so progress is slow. Right now, 18EU hangs in case of a
> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> bankruptcies are rare in 18EU.
>
> I have added comments to the 1835 description on a few remaining issues,
> with workarounds, but otherwise I think it's about done. I have marked
1835
> "almost playable".
>
> Erik.
>
> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday 21 May 2010 18:55
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> > Again some more update:
> >
> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> > More details see below.
> >
> > As Brett and Erik keep quiet about their preference for a release soon,
I
>
> kept
>
> > adding functionality.
>
> Excellent work.
>
> As for when to do a new release, a lot of it is down to how stable
> your changes are.  It sounds like we may be nearing a point where we
> are ready for a new release.
>
> How does next weekend sound?
>
> ---Brett.
>
>
---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

Erik & Brett,
currently quite occupied with other tasks I am only adding small bits in an 
incremental way. I think 1.3.0 is appropriate with a new game supported and 
the first step to revenue and route support.

I have added the support (or better removal) of the Birmingham tile before 
phase 4 by defining an according NetworkGraphModifier interface, which allows 
to adjust the network graph immediately after creation. Changes defined by 
this interface also effect the highlighting for tile and token lays. 

This implies that all titles should be supported, but I am sure there is still 
something is missing, especially for those games which I only know from the 
rulebook.

The fix of the 18EU bankruptcy should allow to close the bug 2954661. 
Game End undos are already possible (I fixed that in 1.2).
Do you think it will be possible to provide an undo possibility for the 
bankruptcy in 18EU as well?

Stefan


On Friday 21 May 2010 22:10:41 Erik Vos wrote:
> Next weekend sounds good. In view of all the great stuff added by Stefan, a
> minor release (1.3.0) might be appropriate?
>
> By now the bugs list is pretty empty; in the past few weeks I have fixed
> quite a lot.
>
> I'm working on the 18EU bankruptcy rules, which were missing. I hope to get
> that done this weekend, but I'm currently much distracted by other
> activities, so progress is slow. Right now, 18EU hangs in case of a
> bankruptcy, but I would't consider that a show-stopper; to my knowledge
> bankruptcies are rare in 18EU.
>
> I have added comments to the 1835 description on a few remaining issues,
> with workarounds, but otherwise I think it's about done. I have marked 1835
> "almost playable".
>
> Erik.
>
> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday 21 May 2010 18:55
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> > Again some more update:
> >
> > Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> > More details see below.
> >
> > As Brett and Erik keep quiet about their preference for a release soon, I
>
> kept
>
> > adding functionality.
>
> Excellent work.
>
> As for when to do a new release, a lot of it is down to how stable
> your changes are.  It sounds like we may be nearing a point where we
> are ready for a new release.
>
> How does next weekend sound?
>
> ---Brett.
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

Next weekend sounds good. In view of all the great stuff added by Stefan, a
minor release (1.3.0) might be appropriate?

By now the bugs list is pretty empty; in the past few weeks I have fixed
quite a lot.

I'm working on the 18EU bankruptcy rules, which were missing. I hope to get
that done this weekend, but I'm currently much distracted by other
activities, so progress is slow. Right now, 18EU hangs in case of a
bankruptcy, but I would't consider that a show-stopper; to my knowledge
bankruptcies are rare in 18EU.
 
I have added comments to the 1835 description on a few remaining issues,
with workarounds, but otherwise I think it's about done. I have marked 1835
"almost playable".

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Friday 21 May 2010 18:55
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I
kept
> adding functionality.

Excellent work.

As for when to do a new release, a lot of it is down to how stable
your changes are.  It sounds like we may be nearing a point where we
are ready for a new release.

How does next weekend sound?

---Brett.

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[brett l. <bre...@gm...>]

On Fri, May 21, 2010 at 9:18 AM, Stefan Frey <ste...@we...> wrote:
> Again some more update:
>
> Full support for 18AL and 18EU is in, 1851 has only Birmingham missing.
> More details see below.
>
> As Brett and Erik keep quiet about their preference for a release soon, I kept
> adding functionality.

Excellent work.

As for when to do a new release, a lot of it is down to how stable
your changes are.  It sounds like we may be nearing a point where we
are ready for a new release.

How does next weekend sound?

---Brett.

Re: [Rails-devel] Implementation details for revenue calculation

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

Again some more update:

Full support for 18AL and 18EU is in, 1851 has only Birmingham missing. 
More details see below.

As Brett and Erik keep quiet about their preference for a release soon, I kept 
adding functionality.
Fortunately this proved to be very easy, as most elements are well prepared. 
I was especially surprised by the excellent support of named trains in 18AL, 
as  without revenue calculation it served no real purpose.
Thus it is not surprising that there are still some minor hassles, which will 
be easy to iron out.

Known open issues:
-> Invisible Birmingham tile
-> Named trains are not assigned after reload
-> 4D in 18AL do not score double (they are not correctly initialized)
-> Graph optimization after off-board area token is not correct

Complete summary of revenue specifics:

Independent tests of those is appreciated.
Map Correction allows to create scenarios easily.
Under NetworkInfo one can run any type of trains in any game, simply use 
standard train type names (like D, 4+4, 10, 5E, 4D).

1830:
Multi-Hex off-board locations

1889:
Diesel Revenue Bonus at off-board locations

1835:
Berlin: No visit of multiple stations (yellow tile only)
Hamburg: Elbe malus
Plus Trains

18EU:
Offboard-Bonus: Dependent on number of tokens visited
Hamburg: Termination vs. Non-Termination
Paris, Berlin, Vienna: No visit of multiple stations
Pullman: Bonus for most valuable city
Trains do not count Towns

18Kaas:
Ruhr: Bonus for other stations/cities

1851
Offboard-2-Offboard: 10 bonus for each stop
Invisible Birmingham: still open

1856
Bonus tokens

18AL
Bonus tokens
Named Trains
Nashville, Mobile: Off-map destinations with token slot
Trains do not count Towns
4D trains

Conversion from Rails to Network attributes:

- If a Rails hex has a value attribute, that value takes preference for all 
stations on that hex, thus the value attribute of the stations of the tile 
laid is irrelevant (no need for -1 or 0).

- Run-Through ("Not a sink") rule listed by priority
1) Off-Map city: No one runs through (even with own token)
2) Slots=0: All run through
3) Nb Tokens = Slots: Only run through with own token
4) Nb Tokens < Slots: All run through
In addition to rule 1: An own token in an off-map city allows to run from.
 
- Location names to identify vertex sets:
The location name is the combination of the city attribute of the hex and city 
tile. If any of them are undefined or equal to "", no location is defined.
Exception are off-map cities, for which only the hex attribute is considered.

Stefan

Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Hi Stefan,

On Wed, 19 May 2010 15:08:24 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex, see comments below.
>
>> By "stations" I meant the station markers (owned by companies). I  
>> thought
>> it's more or less standard term (but now I realize that it might be  
>> just a
>> local dialect). By "city" I meant cities and towns - basically any  
>> vertex
>> with non-zero value.
>
> In fact I allow any vertex to add value (no requirement for a minor/major
> station type), but I do not allow trains to terminate there. (That is not
> important for the games implemented so far, but think about the ferry  
> bonus
> in 18Scan).
Yes, I would have to create artificial vertex in this case (because I  
would remove all intermediate ones).

>> I do the same, but when you reach dead-end, how do you remember what
>> branch (and from what vertex) to try next?
>
> As soon as a deadend is encountered (and after I started the bottom part  
> and
> run other trains), I un-encounter the vertex and return the travelled  
> edge.
> As the encounter calls are recursively the information is on the stack.
> The only need for my own stack of vertices and edges is to store the  
> optimal
> run.
Oh, I see. That essentially means that you're using stack as a way to  
dynamically allocate memory. It probably means that function inlining is  
not working and the actual overhead may show up as a function call  
overhead. Anyway, that's something to look at in the profiler. I was  
hoping you've found some algorithm that was avoiding the need for dynamic  
memory management.

>> I'm sure it's possible to construct scenarios when one method or another
>> will be faster. I was wondering if one method is typically better than
>> another in common scenarios. Btw, how do you deal with "exclusive"  
>> bonuses
>> in this scenarios (for example, train chits in 18AL)?
>>
>
> You mean in the current implementation or with train dominance?
> Currently simple bonuses are covered by the train-dependent vertex  
> values, for
> the complex ones a boolean array controls if a bonus is active for a  
> specific
> train.
> Special train bonuses break train dominance, another reason not for
> implementing it.
I was thinking about both. In particular, the situations when on a given  
route set some bonus can be applied to one of several trains and when  
there're some other bonuses possible (for example one train doubles the  
value of its run (including bonus) and another doesn't).

>> I agree in principle, but I suspect that our current prediction  
>> mechanism
>> already eliminate most of such cases. If you used 10 train for a short
>> route, there will be only so many ways to achieve the threshold with the
>> remaining trains.
>
> The scenarios where it excels compared to revenue predictions are those  
> in
> which you cannot run the trains to the full length.
I am not sure about that... If the optimal route set is achieved on 4+5  
routes, it wouldn't matter which one is served by 8 train and which one is  
by 10. I think it would only make difference on such scenarios where the  
optimal route sets contains routes that have length between the length of  
the trains (for example 6+9 routes for 8+10 trains).

>> I am also curious how much 2-phased approach would help your
>> implementation - with your magic predictor you don't seem to spend much
>> time scanning the routes anyway :)
>>
>
> I hope it is not too "magic", as it will most likely imply that there is
> something wrong. I will think about more tests to rule that out. Are you  
> sure
> you have fully implemented the sequential approach of the revenue  
> prediction
> for the trainset?
No :-) But I can't find anything missing in my implementation. I wonder if  
we either misunderstand what each other counts or someones counting is  
wrong (though mine matching function call count shown by the profiler :) )


Alex.

Re: [Rails-devel] revenue library

[alexti <al...@sh...>]

On Wed, 19 May 2010 14:42:10 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Erik:
> yes you are right:
>
> The city location vertex set rule does not cover cases below.
> And you are right again that (any of) your suggested rule(s) would cover  
> the
> Berlin tile as well.
>
> However there is some reason why I was reluctant to implement your rule:
> The main issue is that is difficult to define the rule first and then to
> transfer it to the vertex graph.
>
> To cut that short:
> 1) Is the rule "only one city on a hex can be visited" (and does this  
> mean
> city or any kind of station?) or "if a train has left any hex,it may not
> reenter that same hex".
>
> 2) Especially the implementation of the latter defintion is particularly  
> hard
> to convert into the vertex structure: If I define all side vertexes as a
> vertex set, a train will never be able to leave the hex again. Most  
> likely
> this requires the addition of additional vertices for entry/departure of  
> the
> hex to control for that (where all of the entry vertices are defined as a
> joint set).
>
> Thus I will live with the simple definition for now and leave the more  
> complex
> cases for later.

If you're going to switch to the 2-phased approach, this situation will be  
easy to describe through segment exclusions - two segments terminating in  
different cities on the same hex are mutually exclusive for the same train.

Re: [Rails-devel] RevenueManager and RevenueStaticModifier

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

On 19 May 2010 22:22, Stefan Frey (web.de) <ste...@we...> wrote:
> Erik & Phil:
> I did not change anything intentionally.
> It is only that my bug fix had the side effect on the toString method for the
> various BonusTokens. Previously the location variable was not initialized
> thus it fell back to the name.
>
> This brings me back to something else:
> I am currently experimenting into how to communciate the bonuses in the
> revenue pop-up message. At the moment it gives more information as needed (to
> allow easier debugging). Later it might be more compact: E.g. in 18Kaas Ruhr
> (20+40+30).
>
> And to ask that here: What should be the default: Should Ruhr double the value
> of both cities and towns or only cities?

Does anyone own a copy of the physical version?  The rules seem to be
sorely lacking on BGG and on the 18XX list, the general consensus
seems to be that it doubles cities only (and that's how we play) but
no doubt someone is going to come back with an alternative they prefer

> And another question:
> What is your opinion on the pop-up messages? Should this be kept active in the
> next release?

I kind of like the popup, although popup messages that block the other
windows from interaction can get annoying sometimes, I don't think
it's a big deal in this case.  For open games with something like a
Diesel you might need to think about cutting the message box text
down.  In the last game of 1856 I ran through, the late game Diesel
run popup was wider than my screen resolution!

> And another one:
> I have implemented that if the Bonus close method is called, it is
> unregistered from the call list of the RevenueManager. Are there other cases,
> when the Bonus gets invalid?
>
> Stefan
>
>
> On Wednesday 19 May 2010 21:03:31 Erik Vos wrote:
>> I think it was John David Galt's request to add token abbreviations ("Br"
>> en "Tu" in 1856). I'd appreciate his opinion.
>> I'm fine with the location names. People might find names easier, but names
>> can only be applied to fixed-location bonuses anyway.
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Wednesday 19 May 2010 14:53
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] RevenueManager and RevenueStaticModifier
>>
>> Hmm, not sure what the majority of people would prefer but I think it
>> would be nice to clearly show that a given location has received a
>> bonus for a token.  I'm not sure most people care what or where the
>> token came from, particularly in 1856 they are usually fairly obvious
>> anyway.
>>
>> Phil
>>
>> On 18 May 2010 23:23, Stefan Frey (web.de) <ste...@we...> wrote:
>> > Again some more results from working on Rails during train rides:
>> >
>> > I added the RevenueManager and the RevenueStaticModifier in Rails.
>> > By those 18Kaas is fully supported and in 1856 Bonus the bonus tokens are
>> > implemented (1856 still misses the support to allow run through the
>>
>> Gooderich
>>
>> > tile).
>> >
>> > Some details:
>> >
>> > -> RevenueManager
>> > A new component similar to the ones like TrainManager, CompanyManager.
>> > This is the only permanent object related to the revenue calculation and
>> > stores the revenue modifiers.
>> >
>> > -> RevenueStaticModifier
>> > This is a (simple) Interface, that requires the implementation of one
>>
>> method:
>> > public void modifyCalculator(RevenueAdapter revenueAdapter)
>> >
>> > This method allows to manipulate all elements for the revenue calculation
>>
>> via
>>
>> > the public methods defined for the revenue adapater. This allows to
>> > create e.g. new vertices, change values of vertices, define additional
>> > RevenueBonuses or vertex sets. Current company and phase are also
>>
>> available.
>>
>> > The method is called each time a revenue adapter was created and
>> > populated from Rails object, but before the revenue calculation occurs.
>> > For this it has to register itself to the RevenueManager via its
>> > addStaticModifier() method.
>> >
>> > Both the RevenueManager and game specific RevenueModifiers can be defined
>> > in Game.xml.
>> >
>> > Example Definition in Game.xml for 18Kaas:
>> >
>> > <Component name="RevenueManager" class="rails.algorithms.RevenueManager">
>> >        <StaticModifier
>>
>> class="rails.game.specific._18Kaas.RuhrRevenueModifier" />
>>
>> > </Component>
>> >
>> > Modifiers defined in that fashion are already registered, thus they do
>> > not need to call addStaticModifier().
>> >
>> > -> Bonus implements RevenueStaticModifier
>> > The Rails class Bonus, which represents an actual Bonus on a hex (exactly
>>
>> what
>>
>> > was neeeded!), implements the modifier above and converts the Rails Bonus
>> > into a RevenueBonus in the calculator.
>> >
>> > An issue here:
>> > Due to a typo in LocatedBonus and SellBonusToken prevented the call to
>> > finishConfiguration (GameManagerI gameManager)
>> > and thus the location variable in Bonus was never parsed.
>> > An side effect of that fix that in the OR window of 1856 the bonus tokens
>>
>> are
>>
>> > shown not a s Tunnel and Bridge token, but by their location codes. I do
>>
>> not
>>
>> > know, what users prefer?
>> >
>> > Stefan
>>
>> ---------------------------------------------------------------------------
>>- --
>>
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>>- --
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ---------------------------------------------------------------------------
>>---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] RevenueManager and RevenueStaticModifier

[Stefan F. (web.de) <ste...@we...>]

Erik & Phil:
I did not change anything intentionally.
It is only that my bug fix had the side effect on the toString method for the 
various BonusTokens. Previously the location variable was not initialized 
thus it fell back to the name.

This brings me back to something else:
I am currently experimenting into how to communciate the bonuses in the
revenue pop-up message. At the moment it gives more information as needed (to 
allow easier debugging). Later it might be more compact: E.g. in 18Kaas Ruhr 
(20+40+30).

And to ask that here: What should be the default: Should Ruhr double the value 
of both cities and towns or only cities?

And another question:
What is your opinion on the pop-up messages? Should this be kept active in the 
next release?

And another one:
I have implemented that if the Bonus close method is called, it is 
unregistered from the call list of the RevenueManager. Are there other cases, 
when the Bonus gets invalid?

Stefan


On Wednesday 19 May 2010 21:03:31 Erik Vos wrote:
> I think it was John David Galt's request to add token abbreviations ("Br"
> en "Tu" in 1856). I'd appreciate his opinion.
> I'm fine with the location names. People might find names easier, but names
> can only be applied to fixed-location bonuses anyway.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Wednesday 19 May 2010 14:53
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] RevenueManager and RevenueStaticModifier
>
> Hmm, not sure what the majority of people would prefer but I think it
> would be nice to clearly show that a given location has received a
> bonus for a token.  I'm not sure most people care what or where the
> token came from, particularly in 1856 they are usually fairly obvious
> anyway.
>
> Phil
>
> On 18 May 2010 23:23, Stefan Frey (web.de) <ste...@we...> wrote:
> > Again some more results from working on Rails during train rides:
> >
> > I added the RevenueManager and the RevenueStaticModifier in Rails.
> > By those 18Kaas is fully supported and in 1856 Bonus the bonus tokens are
> > implemented (1856 still misses the support to allow run through the
>
> Gooderich
>
> > tile).
> >
> > Some details:
> >
> > -> RevenueManager
> > A new component similar to the ones like TrainManager, CompanyManager.
> > This is the only permanent object related to the revenue calculation and
> > stores the revenue modifiers.
> >
> > -> RevenueStaticModifier
> > This is a (simple) Interface, that requires the implementation of one
>
> method:
> > public void modifyCalculator(RevenueAdapter revenueAdapter)
> >
> > This method allows to manipulate all elements for the revenue calculation
>
> via
>
> > the public methods defined for the revenue adapater. This allows to
> > create e.g. new vertices, change values of vertices, define additional
> > RevenueBonuses or vertex sets. Current company and phase are also
>
> available.
>
> > The method is called each time a revenue adapter was created and
> > populated from Rails object, but before the revenue calculation occurs.
> > For this it has to register itself to the RevenueManager via its
> > addStaticModifier() method.
> >
> > Both the RevenueManager and game specific RevenueModifiers can be defined
> > in Game.xml.
> >
> > Example Definition in Game.xml for 18Kaas:
> >
> > <Component name="RevenueManager" class="rails.algorithms.RevenueManager">
> >        <StaticModifier
>
> class="rails.game.specific._18Kaas.RuhrRevenueModifier" />
>
> > </Component>
> >
> > Modifiers defined in that fashion are already registered, thus they do
> > not need to call addStaticModifier().
> >
> > -> Bonus implements RevenueStaticModifier
> > The Rails class Bonus, which represents an actual Bonus on a hex (exactly
>
> what
>
> > was neeeded!), implements the modifier above and converts the Rails Bonus
> > into a RevenueBonus in the calculator.
> >
> > An issue here:
> > Due to a typo in LocatedBonus and SellBonusToken prevented the call to
> > finishConfiguration (GameManagerI gameManager)
> > and thus the location variable in Bonus was never parsed.
> > An side effect of that fix that in the OR window of 1856 the bonus tokens
>
> are
>
> > shown not a s Tunnel and Bridge token, but by their location codes. I do
>
> not
>
> > know, what users prefer?
> >
> > Stefan
>
> ---------------------------------------------------------------------------
>- --
>
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Improved revenue prediction / different scenario

[Stefan F. (web.de) <ste...@we...>]

Alex, see comments below.

> By "stations" I meant the station markers (owned by companies). I thought
> it's more or less standard term (but now I realize that it might be just a
> local dialect). By "city" I meant cities and towns - basically any vertex
> with non-zero value.

In fact I allow any vertex to add value (no requirement for a minor/major 
station type), but I do not allow trains to terminate there. (That is not 
important for the games implemented so far, but think about the ferry bonus 
in 18Scan).

>
> I do the same, but when you reach dead-end, how do you remember what
> branch (and from what vertex) to try next?

As soon as a deadend is encountered (and after I started the bottom part and 
run other trains), I un-encounter the vertex and return the travelled edge. 
As the encounter calls are recursively the information is on the stack. 
The only need for my own stack of vertices and edges is to store the optimal 
run.

>
> I'm sure it's possible to construct scenarios when one method or another
> will be faster. I was wondering if one method is typically better than
> another in common scenarios. Btw, how do you deal with "exclusive" bonuses
> in this scenarios (for example, train chits in 18AL)?
>

You mean in the current implementation or with train dominance?
Currently simple bonuses are covered by the train-dependent vertex values, for 
the complex ones a boolean array controls if a bonus is active for a specific 
train.
Special train bonuses break train dominance, another reason not for 
implementing it.

>
> I agree in principle, but I suspect that our current prediction mechanism
> already eliminate most of such cases. If you used 10 train for a short
> route, there will be only so many ways to achieve the threshold with the
> remaining trains.

The scenarios where it excels compared to revenue predictions are those in 
which you cannot run the trains to the full length.

>
> I am also curious how much 2-phased approach would help your
> implementation - with your magic predictor you don't seem to spend much
> time scanning the routes anyway :)
>

I hope it is not too "magic", as it will most likely imply that there is 
something wrong. I will think about more tests to rule that out. Are you sure 
you have fully implemented the sequential approach of the revenue prediction 
for the trainset?

Stefan

Re: [Rails-devel] revenue library

[Stefan F. (web.de) <ste...@we...>]

Erik:
yes you are right:

The city location vertex set rule does not cover cases below. 
And you are right again that (any of) your suggested rule(s) would cover the 
Berlin tile as well. 

However there is some reason why I was reluctant to implement your rule:
The main issue is that is difficult to define the rule first and then to 
transfer it to the vertex graph. 

To cut that short:
1) Is the rule "only one city on a hex can be visited" (and does this mean 
city or any kind of station?) or "if a train has left any hex,it may not 
reenter that same hex".

2) Especially the implementation of the latter defintion is particularly hard 
to convert into the vertex structure: If I define all side vertexes as a 
vertex set, a train will never be able to leave the hex again. Most likely 
this requires the addition of additional vertices for entry/departure of the 
hex to control for that (where all of the entry vertices are defined as a 
joint set).

Thus I will live with the simple definition for now and leave the more complex 
cases for later.

Stefan


On Wednesday 19 May 2010 20:57:38 Erik Vos wrote:
> Stefan,
>
> I have no major problem with your solution, but I doubt if it will prove to
> be "sustainable" in the long term.
>
> How would you address:
>
> - 1825, where the restriction that only one city on a hex can be visited
> applies to all OO-style hexes? There are quite some of these hexes on all
> the units and regional kits, and the tiles are standard OO tiles.
>
> - 1860, where a similar rule applies to *all* tiles, including such plain
> track tiles as green 16-22, as well as some special tiles. Here the rule
> simply is: if a train has left any hex, it may not reenter that same hex.
> Here it is not a city/station property, not even a hex property but a game
> property.
>
> I'd go for some way to assign that last rule ("if a train has left any hex,
> it may not reenter that same hex") to either selected hexes, or all hexes,
> or (in cases where off-board areas span multiple hexes), sets of hexes.
> Such an approach would cover all cases known to me.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 16 May 2010 23:49
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] revenue library
>
> Erik:
> see below.
>
> On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> > -> Berlin tile still has to be added to the hand-made tiles (city names
> > to block double runs to yellow Berlin).
> >
> > [EV] Does this mean that the one and only function of Station city names
>
> in
>
> > the Tile definitions is to block multiple runs?
> > That does not sound very logical to me. Cannot this blocking feature
>
> (much)
>
> > better be made a (single) MapHex property? Or, if it's colour-dependent,
>
> in
>
> > TileSet?  Like <NoMultipleAccess/> or such?
>
> I found it logical, but I came up with that solution, so that does not mean
> too much. And all solutions have reasonable pro/cons. My reasons were:
>
> A) Choosing the city attribute mirrors the solution for the offboard
> locations/stations. The only difference is that for offboard locations the
> city name (like the revenue value) is defined on the MapHex instead of
> creating different tiles for each off-board area. Allows easy
> implementation.
>
> I only hope that no one ever comes up with two different off-map locations
> combined on one hex, but that would cause headaches for the revenue value
> as
>
> well.
>
> B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to
> split that information over various  files.
>
> C) Why not one property per MapHex/Tile? It allows easily to have
> restrictions
> that combine several hexes/tiles into one vertex set (as I call them). And
> think about a tile with three stations, where only belong to one city.
> I admit that all that is not required for the games currently implemented.
>
> Stefan
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] RevenueManager and RevenueStaticModifier

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

I think it was John David Galt's request to add token abbreviations ("Br" en
"Tu" in 1856). I'd appreciate his opinion. 
I'm fine with the location names. People might find names easier, but names
can only be applied to fixed-location bonuses anyway.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Wednesday 19 May 2010 14:53
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] RevenueManager and RevenueStaticModifier

Hmm, not sure what the majority of people would prefer but I think it
would be nice to clearly show that a given location has received a
bonus for a token.  I'm not sure most people care what or where the
token came from, particularly in 1856 they are usually fairly obvious
anyway.

Phil

On 18 May 2010 23:23, Stefan Frey (web.de) <ste...@we...> wrote:
> Again some more results from working on Rails during train rides:
>
> I added the RevenueManager and the RevenueStaticModifier in Rails.
> By those 18Kaas is fully supported and in 1856 Bonus the bonus tokens are
> implemented (1856 still misses the support to allow run through the
Gooderich
> tile).
>
> Some details:
>
> -> RevenueManager
> A new component similar to the ones like TrainManager, CompanyManager.
> This is the only permanent object related to the revenue calculation and
> stores the revenue modifiers.
>
> -> RevenueStaticModifier
> This is a (simple) Interface, that requires the implementation of one
method:
> public void modifyCalculator(RevenueAdapter revenueAdapter)
>
> This method allows to manipulate all elements for the revenue calculation
via
> the public methods defined for the revenue adapater. This allows to create
> e.g. new vertices, change values of vertices, define additional
> RevenueBonuses or vertex sets. Current company and phase are also
available.
>
> The method is called each time a revenue adapter was created and populated
> from Rails object, but before the revenue calculation occurs.
> For this it has to register itself to the RevenueManager via its
> addStaticModifier() method.
>
> Both the RevenueManager and game specific RevenueModifiers can be defined
> in Game.xml.
>
> Example Definition in Game.xml for 18Kaas:
>
> <Component name="RevenueManager" class="rails.algorithms.RevenueManager">
>        <StaticModifier
class="rails.game.specific._18Kaas.RuhrRevenueModifier" />
> </Component>
>
> Modifiers defined in that fashion are already registered, thus they do not
> need to call addStaticModifier().
>
> -> Bonus implements RevenueStaticModifier
> The Rails class Bonus, which represents an actual Bonus on a hex (exactly
what
> was neeeded!), implements the modifier above and converts the Rails Bonus
> into a RevenueBonus in the calculator.
>
> An issue here:
> Due to a typo in LocatedBonus and SellBonusToken prevented the call to
> finishConfiguration (GameManagerI gameManager)
> and thus the location variable in Bonus was never parsed.
> An side effect of that fix that in the OR window of 1856 the bonus tokens
are
> shown not a s Tunnel and Bridge token, but by their location codes. I do
not
> know, what users prefer?
>
> Stefan
>
>
----------------------------------------------------------------------------
--
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] revenue library

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

Stefan,

I have no major problem with your solution, but I doubt if it will prove to
be "sustainable" in the long term.

How would you address:

- 1825, where the restriction that only one city on a hex can be visited
applies to all OO-style hexes? There are quite some of these hexes on all
the units and regional kits, and the tiles are standard OO tiles.

- 1860, where a similar rule applies to *all* tiles, including such plain
track tiles as green 16-22, as well as some special tiles. Here the rule
simply is: if a train has left any hex, it may not reenter that same hex.
Here it is not a city/station property, not even a hex property but a game
property.

I'd go for some way to assign that last rule ("if a train has left any hex,
it may not reenter that same hex") to either selected hexes, or all hexes,
or (in cases where off-board areas span multiple hexes), sets of hexes. Such
an approach would cover all cases known to me.

Erik.

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Sunday 16 May 2010 23:49
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] revenue library

Erik:
see below.

On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> -> Berlin tile still has to be added to the hand-made tiles (city names to
> block double runs to yellow Berlin).
>
> [EV] Does this mean that the one and only function of Station city names
in
> the Tile definitions is to block multiple runs?
> That does not sound very logical to me. Cannot this blocking feature
(much)
> better be made a (single) MapHex property? Or, if it's colour-dependent,
in
> TileSet?  Like <NoMultipleAccess/> or such?

I found it logical, but I came up with that solution, so that does not mean 
too much. And all solutions have reasonable pro/cons. My reasons were:

A) Choosing the city attribute mirrors the solution for the offboard 
locations/stations. The only difference is that for offboard locations the 
city name (like the revenue value) is defined on the MapHex instead of 
creating different tiles for each off-board area. Allows easy
implementation.

I only hope that no one ever comes up with two different off-map locations 
combined on one hex, but that would cause headaches for the revenue value as

well.

B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to 
split that information over various  files.

C) Why not one property per MapHex/Tile? It allows easily to have
restrictions 
that combine several hexes/tiles into one vertex set (as I call them). And 
think about a tile with three stations, where only belong to one city.
I admit that all that is not required for the games currently implemented.

Stefan

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] RevenueManager and RevenueStaticModifier

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

Hmm, not sure what the majority of people would prefer but I think it
would be nice to clearly show that a given location has received a
bonus for a token.  I'm not sure most people care what or where the
token came from, particularly in 1856 they are usually fairly obvious
anyway.

Phil

On 18 May 2010 23:23, Stefan Frey (web.de) <ste...@we...> wrote:
> Again some more results from working on Rails during train rides:
>
> I added the RevenueManager and the RevenueStaticModifier in Rails.
> By those 18Kaas is fully supported and in 1856 Bonus the bonus tokens are
> implemented (1856 still misses the support to allow run through the Gooderich
> tile).
>
> Some details:
>
> -> RevenueManager
> A new component similar to the ones like TrainManager, CompanyManager.
> This is the only permanent object related to the revenue calculation and
> stores the revenue modifiers.
>
> -> RevenueStaticModifier
> This is a (simple) Interface, that requires the implementation of one method:
> public void modifyCalculator(RevenueAdapter revenueAdapter)
>
> This method allows to manipulate all elements for the revenue calculation via
> the public methods defined for the revenue adapater. This allows to create
> e.g. new vertices, change values of vertices, define additional
> RevenueBonuses or vertex sets. Current company and phase are also available.
>
> The method is called each time a revenue adapter was created and populated
> from Rails object, but before the revenue calculation occurs.
> For this it has to register itself to the RevenueManager via its
> addStaticModifier() method.
>
> Both the RevenueManager and game specific RevenueModifiers can be defined
> in Game.xml.
>
> Example Definition in Game.xml for 18Kaas:
>
> <Component name="RevenueManager" class="rails.algorithms.RevenueManager">
>        <StaticModifier class="rails.game.specific._18Kaas.RuhrRevenueModifier" />
> </Component>
>
> Modifiers defined in that fashion are already registered, thus they do not
> need to call addStaticModifier().
>
> -> Bonus implements RevenueStaticModifier
> The Rails class Bonus, which represents an actual Bonus on a hex (exactly what
> was neeeded!), implements the modifier above and converts the Rails Bonus
> into a RevenueBonus in the calculator.
>
> An issue here:
> Due to a typo in LocatedBonus and SellBonusToken prevented the call to
> finishConfiguration (GameManagerI gameManager)
> and thus the location variable in Bonus was never parsed.
> An side effect of that fix that in the OR window of 1856 the bonus tokens are
> shown not a s Tunnel and Bridge token, but by their location codes. I do not
> know, what users prefer?
>
> Stefan
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Stefan,

On Tue, 18 May 2010 16:05:27 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex, see comments below:
>
> On Monday 17 May 2010 01:37:17 alexti wrote:
>> Stefan,
>>
>> I think you iterate in some completely different manner. I am still  
>> unsure
>> what you do when you encounter a "branch" during the iteration. For
>> example station is connected to the city with 6 exits, so when you
>> consider the route from the station to this city it can continue in 5
>> different directions. How do you iterate over these directions?
>>
>
> I do not exactly understand your definition of "station" and "city" above
> (maybe related to the fact that there is some confusing usage of station  
> and
> city in Rails as well).
By "stations" I meant the station markers (owned by companies). I thought  
it's more or less standard term (but now I realize that it might be just a  
local dialect). By "city" I meant cities and towns - basically any vertex  
with non-zero value.

>
> For the revenue calculator station is a vertex that (usually) counts for  
> the
> train lengths and there are subtypes major (cities and equivalents) and  
> minor
> (towns and equivalents).
>
> I assume you mean what happens when a city/major station is encountered,  
> which
> is connected to all sides of the hex:
>
> The branching is easy, I will try all exits in the ordering of the  
> neighbor
> vertex id in a depth-first manner. Actually I check the incoming exit  
> to, but
> this will fail as the required edge is used already.
I do the same, but when you reach dead-end, how do you remember what  
branch (and from what vertex) to try next?

>> This is an interesting idea. This operation would be equivalent to my
>> "evaluation". I would imagine it's faster when you are "extending" your
>> route, but when you switch between "branches" you would have to "undo"  
>> by
>> removing values added in the old branch. I wonder if it's faster that
>> recomputing from scratch every time...
>
> Exactly: All encounter vertex and travel edge operations have equivalent
> un-encounter and un-travel equivalents. In fact the encounter method has  
> a
> simple boolean switch to indicate arrival/departure.
> If that is faster, I do not know, most likely it will depend on the  
> scenario.
I'm sure it's possible to construct scenarios when one method or another  
will be faster. I was wondering if one method is typically better than  
another in common scenarios. Btw, how do you deal with "exclusive" bonuses  
in this scenarios (for example, train chits in 18AL)?

>>
>> My run time is currently divided approximately 50-50 between the train
>> revenue calculation and everything else (iterating over possible routes,
>> including validity of those routes etc). Where do you spend most of the
>> time?
>
> I have not done any profiling so far. I am more than satisfied with the  
> speed
> so far and currently focus on the integration of the specific features  
> for
> the implemented games. And before profiling I would add the two-phase
> approach, that works pretty well for you.  And my target is not to add  
> any AI
> type, thus there is no need to consider what-if scenarios.
>
> In fact I have still one idea to improve the tree cutting especially for
> train-sets: My working title for that is train dominance. It formalizes  
> what
> a human player usually does. Take the example you search for optimal  
> routes
> for an 8 and a 10 train: You would never consider the combination where  
> the 8
> trains runs a longer route than the 10 train. In fact you look for the  
> best
> combination of a route with maximum length of 8 and one with maximum  
> length
> of 10. Thus there is no need to evaluate any route combination, where  
> the 10
> train runs for less stations than the 8. I still do that currently.
> You could also define that the latter 8 has to dominate the former 8.
> That would be pretty easy to check, but...
>
> What makes the things a little more difficult is the fact to consider  
> those
> cases, where the assumption above is not valid or not that easy:
>
> * A 5 train is not dominant to a 3+3, nor is the 3+3 dominant to the 5.  
> But at
> least a 8 dominates the 3+3 and a 3+3 dominates the 3.
> * Trains that ignore minors, are not dominant to non-ignoring trains and  
> vice
> versa.
> * Trains with an increased scoring factor, can never be dominated by  
> longer
> trains with a lower scoring factor. Thus neither a 10 train dominates the
> doubling 4, nor vice versa.
> * Train-specific bonuses makes all dominance assumptions for that train
> invalid.
>
> But it might be still worthwile to look into, as it could potentially  
> promise
> a substantial speed increase for cases, where the dominance relation is  
> well
> defined.
I agree in principle, but I suspect that our current prediction mechanism  
already eliminate most of such cases. If you used 10 train for a short  
route, there will be only so many ways to achieve the threshold with the  
remaining trains.

I am also curious how much 2-phased approach would help your  
implementation - with your magic predictor you don't seem to spend much  
time scanning the routes anyway :)

Alex.

>
> Stefan
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Rails-devel] RevenueManager and RevenueStaticModifier

[Stefan F. (web.de) <ste...@we...>]

Again some more results from working on Rails during train rides:

I added the RevenueManager and the RevenueStaticModifier in Rails.
By those 18Kaas is fully supported and in 1856 Bonus the bonus tokens are 
implemented (1856 still misses the support to allow run through the Gooderich 
tile).

Some details:

-> RevenueManager
A new component similar to the ones like TrainManager, CompanyManager.
This is the only permanent object related to the revenue calculation and 
stores the revenue modifiers.

-> RevenueStaticModifier
This is a (simple) Interface, that requires the implementation of one method:
public void modifyCalculator(RevenueAdapter revenueAdapter)

This method allows to manipulate all elements for the revenue calculation via 
the public methods defined for the revenue adapater. This allows to create 
e.g. new vertices, change values of vertices, define additional 
RevenueBonuses or vertex sets. Current company and phase are also available.

The method is called each time a revenue adapter was created and populated 
from Rails object, but before the revenue calculation occurs.
For this it has to register itself to the RevenueManager via its 
addStaticModifier() method.

Both the RevenueManager and game specific RevenueModifiers can be defined
in Game.xml.

Example Definition in Game.xml for 18Kaas:

<Component name="RevenueManager" class="rails.algorithms.RevenueManager">
	<StaticModifier class="rails.game.specific._18Kaas.RuhrRevenueModifier" /> 
</Component>

Modifiers defined in that fashion are already registered, thus they do not 
need to call addStaticModifier().

-> Bonus implements RevenueStaticModifier 
The Rails class Bonus, which represents an actual Bonus on a hex (exactly what 
was neeeded!), implements the modifier above and converts the Rails Bonus 
into a RevenueBonus in the calculator. 

An issue here:
Due to a typo in LocatedBonus and SellBonusToken prevented the call to
finishConfiguration (GameManagerI gameManager)
and thus the location variable in Bonus was never parsed.
An side effect of that fix that in the OR window of 1856 the bonus tokens are 
shown not a s Tunnel and Bridge token, but by their location codes. I do not 
know, what users prefer?

Stefan

Re: [Rails-devel] Improved revenue prediction / different scenario

[Stefan F. (web.de) <ste...@we...>]

Alex, see comments below:

On Monday 17 May 2010 01:37:17 alexti wrote:
> Stefan,
>
> I think you iterate in some completely different manner. I am still unsure
> what you do when you encounter a "branch" during the iteration. For
> example station is connected to the city with 6 exits, so when you
> consider the route from the station to this city it can continue in 5
> different directions. How do you iterate over these directions?
>

I do not exactly understand your definition of "station" and "city" above 
(maybe related to the fact that there is some confusing usage of station and  
city in Rails as well).

For the revenue calculator station is a vertex that (usually) counts for the 
train lengths and there are subtypes major (cities and equivalents) and minor 
(towns and equivalents).

I assume you mean what happens when a city/major station is encountered, which 
is connected to all sides of the hex:

The branching is easy, I will try all exits in the ordering of the neighbor 
vertex id in a depth-first manner. Actually I check the incoming exit to, but 
this will fail as the required edge is used already.

> This is an interesting idea. This operation would be equivalent to my
> "evaluation". I would imagine it's faster when you are "extending" your
> route, but when you switch between "branches" you would have to "undo" by
> removing values added in the old branch. I wonder if it's faster that
> recomputing from scratch every time...

Exactly: All encounter vertex and travel edge operations have equivalent 
un-encounter and un-travel equivalents. In fact the encounter method has a
simple boolean switch to indicate arrival/departure.
If that is faster, I do not know, most likely it will depend on the scenario.
>
> My run time is currently divided approximately 50-50 between the train
> revenue calculation and everything else (iterating over possible routes,
> including validity of those routes etc). Where do you spend most of the
> time?

I have not done any profiling so far. I am more than satisfied with the speed 
so far and currently focus on the integration of the specific features for 
the implemented games. And before profiling I would add the two-phase 
approach, that works pretty well for you.  And my target is not to add any AI 
type, thus there is no need to consider what-if scenarios.

In fact I have still one idea to improve the tree cutting especially for 
train-sets: My working title for that is train dominance. It formalizes what 
a human player usually does. Take the example you search for optimal routes 
for an 8 and a 10 train: You would never consider the combination where the 8 
trains runs a longer route than the 10 train. In fact you look for the best 
combination of a route with maximum length of 8 and one with maximum length 
of 10. Thus there is no need to evaluate any route combination, where the 10 
train runs for less stations than the 8. I still do that currently. 
You could also define that the latter 8 has to dominate the former 8.
That would be pretty easy to check, but...

What makes the things a little more difficult is the fact to consider those 
cases, where the assumption above is not valid or not that easy:

* A 5 train is not dominant to a 3+3, nor is the 3+3 dominant to the 5. But at 
least a 8 dominates the 3+3 and a 3+3 dominates the 3.
* Trains that ignore minors, are not dominant to non-ignoring trains and vice 
versa.
* Trains with an increased scoring factor, can never be dominated by longer 
trains with a lower scoring factor. Thus neither a 10 train dominates the 
doubling 4, nor vice versa.
* Train-specific bonuses makes all dominance assumptions for that train 
invalid. 

But it might be still worthwile to look into, as it could potentially promise 
a substantial speed increase for cases, where the dominance relation is well 
defined.

Stefan

Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Stefan,

I think you iterate in some completely different manner. I am still unsure  
what you do when you encounter a "branch" during the iteration. For  
example station is connected to the city with 6 exits, so when you  
consider the route from the station to this city it can continue in 5  
different directions. How do you iterate over these directions?


> In fact I do not sum up  the revenue of the routes from vertex values  
> each
> time, but I update the currentTrainValues each time a vertex is  
> encountered
> or left. The only summation is done over the set of trains. The  
> separation
> into single trains (instead of updating a joint value) allows the revenue
> prediction of the current running train.
This is an interesting idea. This operation would be equivalent to my  
"evaluation". I would imagine it's faster when you are "extending" your  
route, but when you switch between "branches" you would have to "undo" by  
removing values added in the old branch. I wonder if it's faster that  
recomputing from scratch every time...

My run time is currently divided approximately 50-50 between the train  
revenue calculation and everything else (iterating over possible routes,  
including validity of those routes etc). Where do you spend most of the  
time?

Alex.



On Sun, 16 May 2010 15:32:28 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex,
> answers and comments see below:
>
>> I am curious, how do you avoid dynamic memory allocation during the
>> iteration through the routes? With the switch to the two-phased  
>> approach I
>> also couldn't avoid some dynamic sizing in the second phase graph.
>>
>
> I convert all information from the graph and other objects into a simple
> arrays, where I define the size at the initialization of the revenue
> calculator (usually to the maximum number of trains, vertices, edges  
> etc).
> Thus I never create any objects throughout the iterations.
>
> The dynamic data arrays are:
>     // dynamic train data
>     private final int[] trainCurrentValue;
>     private final int[] trainMajors;
>     private final int[] trainMinors;
>     private final boolean[][] trainVisited; // dimensions: train, vertex
>     private final int[][] trainVertexStack; // dimensions: train, vertex
>     private final int[][] trainEdgeStack; // dimensions: train, edge
>     private final int[] trainStackPos;
>     private final int [] trainBottomPos;
>     private final int [] trainStartEdge;
>
>     // dynamic bonus data
>     private final int [][] bonusTrainVertices; // dimensions: bonus,  
> train
>
>> >> What exactly 5,651k predictions in your case mean?
>> >
>> > Evaluations count the call to the function that sums up the value of  
>> all
>> > trains after all trains are finished.
>>
>> Can you tell from this number how many times revenue of the route has  
>> been
>> computed?
>
> In fact I do not sum up  the revenue of the routes from vertex values  
> each
> time, but I update the currentTrainValues each time a vertex is  
> encountered
> or left. The only summation is done over the set of trains. The  
> separation
> into single trains (instead of updating a joint value) allows the revenue
> prediction of the current running train.
>
>>
>> > Predictions count the call to the function used after each station  
>> visit.
>> >
>> > Actually the latest refactoring (I do not evaluate anymore until I  
>> reach
>> > the
>> > second station, previously I set that to zero) reduced the number of
>> > evaluations and predictions:
>> > The number of evaluations drops to 480k, the number of predictions to
>> > 2,950k, the number of edges travelled does not change.
>> > Speed improvement is minor (10-15%).
>>
>> This sounds like what I was calling revenue of the route computation. Is
>> it the place were you total value of cities and apply bonuses?
>
> As mentioned above, I do not total city values at the evaluation, but
> continuously. The only summation is over trains.
>
> Bonuses are added to the current train value when they are scored or
> (un-)scored again. For each bonus/train combination a counter is  
> initialized
> with  the number of required vertices (this is the bonusTrainVertices  
> array
> above). Each time a trains visit a required vertex, the counter for that
> bonus is decreased. If zero is reached the bonus value is added. If the
> counter increases to one again, the bonus value is subtracted.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] revenue library

[Stefan F. (web.de) <ste...@we...>]

Erik:
see below.

On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> -> Berlin tile still has to be added to the hand-made tiles (city names to
> block double runs to yellow Berlin).
>
> [EV] Does this mean that the one and only function of Station city names in
> the Tile definitions is to block multiple runs?
> That does not sound very logical to me. Cannot this blocking feature (much)
> better be made a (single) MapHex property? Or, if it's colour-dependent, in
> TileSet?  Like <NoMultipleAccess/> or such?

I found it logical, but I came up with that solution, so that does not mean 
too much. And all solutions have reasonable pro/cons. My reasons were:

A) Choosing the city attribute mirrors the solution for the offboard 
locations/stations. The only difference is that for offboard locations the 
city name (like the revenue value) is defined on the MapHex instead of 
creating different tiles for each off-board area. Allows easy implementation.

I only hope that no one ever comes up with two different off-map locations 
combined on one hex, but that would cause headaches for the revenue value as 
well.

B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to 
split that information over various  files.

C) Why not one property per MapHex/Tile? It allows easily to have restrictions 
that combine several hexes/tiles into one vertex set (as I call them). And 
think about a tile with three stations, where only belong to one city.
I admit that all that is not required for the games currently implemented.

Stefan

Re: [Rails-devel] Improved revenue prediction / different scenario

[Stefan F. (web.de) <ste...@we...>]

Alex,
answers and comments see below:

> I am curious, how do you avoid dynamic memory allocation during the
> iteration through the routes? With the switch to the two-phased approach I
> also couldn't avoid some dynamic sizing in the second phase graph.
>

I convert all information from the graph and other objects into a simple 
arrays, where I define the size at the initialization of the revenue 
calculator (usually to the maximum number of trains, vertices, edges etc).
Thus I never create any objects throughout the iterations.

The dynamic data arrays are:
    // dynamic train data
    private final int[] trainCurrentValue;
    private final int[] trainMajors;
    private final int[] trainMinors;
    private final boolean[][] trainVisited; // dimensions: train, vertex
    private final int[][] trainVertexStack; // dimensions: train, vertex
    private final int[][] trainEdgeStack; // dimensions: train, edge
    private final int[] trainStackPos;
    private final int [] trainBottomPos;
    private final int [] trainStartEdge;

    // dynamic bonus data
    private final int [][] bonusTrainVertices; // dimensions: bonus, train

> >> What exactly 5,651k predictions in your case mean?
> >
> > Evaluations count the call to the function that sums up the value of all
> > trains after all trains are finished.
>
> Can you tell from this number how many times revenue of the route has been
> computed?

In fact I do not sum up  the revenue of the routes from vertex values each 
time, but I update the currentTrainValues each time a vertex is encountered 
or left. The only summation is done over the set of trains. The separation 
into single trains (instead of updating a joint value) allows the revenue 
prediction of the current running train. 

>
> > Predictions count the call to the function used after each station visit.
> >
> > Actually the latest refactoring (I do not evaluate anymore until I reach
> > the
> > second station, previously I set that to zero) reduced the number of
> > evaluations and predictions:
> > The number of evaluations drops to 480k, the number of predictions to
> > 2,950k, the number of edges travelled does not change.
> > Speed improvement is minor (10-15%).
>
> This sounds like what I was calling revenue of the route computation. Is
> it the place were you total value of cities and apply bonuses?

As mentioned above, I do not total city values at the evaluation, but 
continuously. The only summation is over trains.

Bonuses are added to the current train value when they are scored or 
(un-)scored again. For each bonus/train combination a counter is initialized 
with  the number of required vertices (this is the bonusTrainVertices array 
above). Each time a trains visit a required vertex, the counter for that 
bonus is decreased. If zero is reached the bonus value is added. If the 
counter increases to one again, the bonus value is subtracted.

Re: [Rails-devel] revenue library

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

Yes, I have just fixed that one too. Should work now. 
Erik.

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Sunday 16 May 2010 23:01
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] revenue library

Erik:
thanks a lot. At least in my case I have to copy the color definitions to my
properties file and uncomment the colors, otherwise I cannot start or load
any 
game. Same is true for running from the supplied my.properties without 
uncommenting the error is raised:

Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at rails.ui.swing.MapPanel.<init>(MapPanel.java:40)

Stefan
 

On Sunday 16 May 2010 00:46:15 Erik Vos wrote:
> nd another question: Anyone suggest better colors (RGB values) for the
> routing paths. I do not know, if I have time to figure out, how I make
> those
>
> configurable from the properties file.
>
> [EV] I'm willing to look at that.
>
> [EV2] Now done. See the new my.properties file.
>
>
>
---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel