Re: [Rails-devel] Experimental version of revenue calculation

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

Stefan,

A quick test on my currently running 18Kaas game threw up one thing
for the algorithm and a vaguely related issue that certainly needs
consideration for automatic revenue generation.

I generated the network info for NYNH in the attached scenario,
firstly, it ran one of the 2 trains by just counting the revenue for
hex G10 on it's own.  In this case NYNH doesn't really have 3 legal
runs for it's 3 trains so I understand why it did this.  It needs to
be limited to not allow runs of only one station (unless there is a
game out there that allows this that I am unaware of?).

The second issue (and less of an algorithm problem) is that the Ruhr
is listed as an income of 2.  This is simply how I assume we have
chosen to represent the 'doubles cities' power of the Ruhr offboard.
If revenue generation is to work for 18Kaas we will need to represent
this differently.  Of course, that is a whole other discussion on it's
own, as far as I can tell different gaming groups handle this rule
totally differently so there may be some discussion as to what the
official ruling is!

Phil

On 12 April 2010 18:50, Stefan Frey (web.de) <ste...@we...> wrote:
> There is a first working version for revenue calculation in CVS.
> The interface is minimal and added to the graph view:
>
> Thus in the ORWindow select Info => NetworkInfo and the
> public company. Then the graph is displayed and the optimal revenue result and
> the vertexes run for each train for the result.
>
> After this one can add additional trains and the optimization restarts.
>
> For available traintypes (currently default (including diesel), +, E and D
> trains) check the addTrainByString method in RevenueAdapter.
>
> BE CAREFUL:
> 1) It generates a lot of debug in the 18xx.log if the logging level is set to
> DEBUG (as it is the default). If one tests complicated cases it can fill up
> the hd quite quickly. Better have an own properties with debug level set to
> INFO.
>
> 2) I cannot guarantee that it will not run into a deadlock, thus it can freeze
> the UI and generate lots of debug output. Again see 1) and kill the program
> after around 5 minutes latest.
>
> But for reasonable (up to moderate difficult) networks it will give results
> nearly immediately.
>
> This is still not the algorithm of Alex, which has pretty amazing running
> times, but a simple brute force algorithm on the current (moderately
> optimized) network graph.
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>