rails-devel — List for discussion of Rails development

[Rails-devel] Patch

[John D. G. <jd...@di...>]

This adds code to PublicCompany.getBaseTokenLayCost() so that the "distance"
factor (cost per hex distance) can be different for each token in sequence.

rails/game/PublicCompany.java
1753        /**
1754         * Calculate the cost of laying a token, given the hex where
1755         * the token is laid. This only makes a difference for the "distance" method.
1756         * @param hex The hex where the token is to be laid.
1757         * @return The cost of laying that token.
1758         */
1759        public int getBaseTokenLayCost(MapHex hex) {
1760    
1761            if (baseTokenLayCost == null) return 0;
1762    
     +          if (index >= baseTokenLayCost.length) {
     +              index = baseTokenLayCost.length - 1;
     +          } else if (index < 0) {
     +              index = 0;
     +          }
1763            if (baseTokenLayCostMethod.equals(BASE_COST_SEQUENCE)) {
1764 -              int index = getNumberOfLaidBaseTokens();
1765 -  
1766 -              if (index >= baseTokenLayCost.length) {
1767 -                  index = baseTokenLayCost.length - 1;
1768 -              } else if (index < 0) {
1769 -                  index = 0;
1770 -              }
1771                return baseTokenLayCost[index];
1772            } else if (baseTokenLayCostMethod.equals(BASE_COST_DISTANCE)) {
1773                if (hex == null) {
1774 -                  return baseTokenLayCost[0];
     +                  return baseTokenLayCost[index];
1775                } else {
1776                    // WARNING: no provision yet for multiple home hexes.
1777 -                  return mapManager.getHexDistance(homeHexes.get(0), hex) * baseTokenLayCost[0];
     +                  return mapManager.getHexDistance(homeHexes.get(0), hex) * baseTokenLayCost[index];
1778                }
1779            } else {
1780                return 0;
1781            }
1782        }

Re: [Rails-devel] An ongoing rails issue

[John D. G. <jd...@di...>]

On 2012-05-31 07:42, Chris Shaffer wrote:
> Are other people experiencing the same problem?

I'm not, and I have what I consider quite a slow system (Dell, 2.79GHz, 1GB RAM).
At least, when reading mail I get enough long delays that I frequently hit
repeat-Ctrl-Alt-Del.  The system is otherwise quite nice, but won't take more RAM.

Re: [Rails-devel] Stop properties framework

[John D. G. <jd...@di...>]

On 2012-05-31 15:25, Erik Vos wrote:
> I'm happy to report that I have made quite some progress with the new Stop
> properties framework, that was discussed a while ago.

I like the general framework, but wanted to toss in a few comments, so I will
snip all the parts I'm not commenting on.

> The stop properties are now collected in a new class named Access.
[snip]
> - runTo (can a train run to a certain station?).  Still unused.  It is
> intended to configure initial access restrictions like those of 1851
> Birmingham and 1835 Elsass-Lothringen.

runTo sounds more like a train attribute which says which kinds of stops a
particular train can visit.  I'd suggest we either call this option something
like disable="yes", or use some "magic" revenue value (say, -9999) to mean
that no train can go there.  (The advantage of the latter approach is that
the existing OffBoardRevenue mechanism in data/Game.xml can turn it on/off.)

> - loop (can a train re-enter a hex visited before?). Still unused, and
> perhaps redundant.  It was intended to prevent the Paris/Berlin/Vienna loop
> problems in 18EU and 1835, but that issue can be equally well addressed by
> the trainMutexID, to be discussed below. 'loop' may still prove useful for
> 1860, where no train may re-enter ANY hex. 

I like the idea of "loop" being a tile or hex option, because some games allow
a train to visit any city tile more than once (but not the same city), while
other games allow this for multiple-large-city tiles but not for multiple-dit
tiles (1853, if I recall).

By the way, in 18EU, this rule does not just affect train runs.  A route that
starts in Berlin (NW), passes through an empty token space in Berlin (NE), and
then goes to Wien is not a legal route for any purpose.  Thus a company in
Berlin (NW) would not be allowed to build track if its connection to the new
track must pass through Berlin (NE); nor would a minor company in Berlin (NW)
be allowed to merge into a major company in Wien during the final exchange
round.

> - score type: major or minor (e.g. for 1835 n+m trains and for the many
> games where towns do not count against the train size).  This is the only
> stop property already in use.  The new framework allows more fine-grained
> configuration.

1837 also has express trains (4E, 5E) which completely ignore dits.  I'd want
a way to set that behavior as a property of the train type.

> Stefan, I was wondering why your setting of city="B/V" for the Berlin/Vienna
> tiles in 18EU did prevent one-hex loopback, but not the Berlin-Vienna route.
> I guess you are doing this check per hex only.  If you could lift that
> restriction, and look at duplicate city names (or whatever) on all stops of
> a route, I think we would have a strong mechanism to achieve all kinds of
> train access limitations.

Your trainMutexID is a better idea than using city names for this.  City names
are generally one per hex, and not all games even name the cities.  (And then
there are the dual city spaces like the OO's in 1830 and the 404s in 1837,
where there are two city names but it may not be possible to tell which is
which, such as if Philadelphia/Camden is laid with one city north of the
other.)

[Rails-devel] 1856 revenue bug (1.7.5)

[John D. G. <jd...@di...>]

In this saved game, LPS bought in the tunnel private just before declaring its
dividend.  However, the calculated revenue did not increase to 120 because LPS
now has tunnel rights.  I had to make that change manually.

Re: [Rails-devel] Revenue calculation performance

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

Nice entry for the wiki!

> To turn of logging for the revenue calculation:
> 
> * If you have a working development setup simply change a line inside
> log4j.properties (change from INFO to FATAL).
> 
> # log4j.logger.rails.algorithms=INFO
> log4j.logger.rails.algorithms=FATAL
> 
> * If you use the latest release version:
> 
> Copy the attached logging file into the working directory of rails (that
with
> the rails jar and rails.sh rails-bat) and start rails with this
> command:
> 
> java -Dlog4j.configuration="file:log4j_woa.properties" -jar
rails-1.7.5.jar
> 
> Stefan

Re: [Rails-devel] Stop properties framework

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

> Not counting towns/minors towards the train length is a train attribute
and
> not a stop attribute. (countTown=yes/no).

Indeed, for the known cases we don't need a third value.
I'm a bit unsure about the 1860 halts, but let's address that issue when
(and if!) the time comes.

Erik.

Re: [Rails-devel] Update of the logging framework

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

I consider log4j good enough, but I have no real objections.  

In an slf4j example I noticed the use of {} placeholders in the logged text, with arguments, and I like that. 
On first sight, logback looks slightly better than log4j.  Not sure if the documentation is that much better, though: I had to click around for a while before I found a few more than trivial code examples. But I guess that's just me.

Go ahead if you prefer it.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday, June 01, 2012 6:06 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Update of the logging framework
> 
> Stefan -
> 
> That's good enough for me. Using better-supported, better-documented
> tools is a win. :-)
> 
> ---Brett.
> 
> 
> On Fri, Jun 1, 2012 at 11:56 AM, Stefan Frey <ste...@we...> wrote:
> > Brett:
> > Main limitation is the much better documentation. And there is not
> > much documentation on log4j except the api and few introductory
> documents.
> > Compare this to one below.
> >
> > The reason I had to look for documentation was mainly how to
> > include/enable/disable the log4j logging during unit testing.
> >
> > And from the developers involved logback is log4j version 2 anyway.
> >
> > Stefan
> >
> > On 06/01/2012 05:40 PM, brett lentz wrote:
> >> Stefan -
> >>
> >> I don't object to it outright, but I would like to see more info on
> >> why such a change is being made before it's implemented.
> >>
> >> What limitations of log4j would we be overcoming?
> >> What essential features does sl4j and logback have that log4j doesn't?
> >> Would updating log4j change the comparison any?
> >>
> >> I'm not really tied to one solution over another, but I'd like to
> >> understand what we're gaining or losing by switching.
> >>
> >> ---Brett.
> >>
> >>
> >> On Fri, Jun 1, 2012 at 11:36 AM, Stefan
> Frey<ste...@we...>  wrote:
> >>> Erik&  Brett:
> >>> taking the opportunity of a major update to Rails 2.0 I suggest to
> >>> replace the log4j logging by the combination of sl4j and logback.
> >>>
> >>> See http://slf4j.org/ and http://logback.qos.ch/index.html for details.
> >>>
> >>> Any objections?
> >>>
> >>> Stefan
> >>>
> >>> --------------------------------------------------------------------
> >>> ----------
> >>> Live Security Virtual Conference
> >>> Exclusive live event will cover all the ways today's security and
> >>> threat landscape has changed and how IT managers can respond.
> >>> Discussions will include endpoint security, mobile security and the
> >>> latest in malware threats.
> >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >>> _______________________________________________
> >>> Rails-devel mailing list
> >>> Rai...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >> ---------------------------------------------------------------------
> >> ---------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> >> Discussions will include endpoint security, mobile security and the
> >> latest in malware threats.
> >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Revenue calculation performance

[Mike B. <com...@ip...>]

Thanks, Stefan. I'll give it a try on Sunday. I've generated an 1856
savegame at the point where things slow down massively - it roughly
coincides with the log file hitting 25Mb in size (25,273K to be precise). As
soon as I get hold of a functioning stopwatch, I'll run some tests and set
some benchmarks.

PS: I think I misidentified the game that is especially bad. I meant 1856.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com





---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120531-1, 01/06/2012
Tested on: 2/06/2012 2:45:44 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Update of the logging framework

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

Stefan -

That's good enough for me. Using better-supported, better-documented
tools is a win. :-)

---Brett.


On Fri, Jun 1, 2012 at 11:56 AM, Stefan Frey <ste...@we...> wrote:
> Brett:
> Main limitation is the much better documentation. And there is not much
> documentation on log4j except the api and few introductory documents.
> Compare this to one below.
>
> The reason I had to look for documentation was mainly how to
> include/enable/disable the log4j logging during unit testing.
>
> And from the developers involved logback is log4j version 2 anyway.
>
> Stefan
>
> On 06/01/2012 05:40 PM, brett lentz wrote:
>> Stefan -
>>
>> I don't object to it outright, but I would like to see more info on
>> why such a change is being made before it's implemented.
>>
>> What limitations of log4j would we be overcoming?
>> What essential features does sl4j and logback have that log4j doesn't?
>> Would updating log4j change the comparison any?
>>
>> I'm not really tied to one solution over another, but I'd like to
>> understand what we're gaining or losing by switching.
>>
>> ---Brett.
>>
>>
>> On Fri, Jun 1, 2012 at 11:36 AM, Stefan Frey<ste...@we...>  wrote:
>>> Erik&  Brett:
>>> taking the opportunity of a major update to Rails 2.0 I suggest to
>>> replace the log4j logging by the combination of sl4j and logback.
>>>
>>> See http://slf4j.org/ and http://logback.qos.ch/index.html for details.
>>>
>>> Any objections?
>>>
>>> Stefan
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Update of the logging framework

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

Brett:
Main limitation is the much better documentation. And there is not much 
documentation on log4j except the api and few introductory documents. 
Compare this to one below.

The reason I had to look for documentation was mainly how to 
include/enable/disable the log4j logging during unit testing.

And from the developers involved logback is log4j version 2 anyway.

Stefan

On 06/01/2012 05:40 PM, brett lentz wrote:
> Stefan -
>
> I don't object to it outright, but I would like to see more info on
> why such a change is being made before it's implemented.
>
> What limitations of log4j would we be overcoming?
> What essential features does sl4j and logback have that log4j doesn't?
> Would updating log4j change the comparison any?
>
> I'm not really tied to one solution over another, but I'd like to
> understand what we're gaining or losing by switching.
>
> ---Brett.
>
>
> On Fri, Jun 1, 2012 at 11:36 AM, Stefan Frey<ste...@we...>  wrote:
>> Erik&  Brett:
>> taking the opportunity of a major update to Rails 2.0 I suggest to
>> replace the log4j logging by the combination of sl4j and logback.
>>
>> See http://slf4j.org/ and http://logback.qos.ch/index.html for details.
>>
>> Any objections?
>>
>> Stefan
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Update of the logging framework

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

Stefan -

I don't object to it outright, but I would like to see more info on
why such a change is being made before it's implemented.

What limitations of log4j would we be overcoming?
What essential features does sl4j and logback have that log4j doesn't?
Would updating log4j change the comparison any?

I'm not really tied to one solution over another, but I'd like to
understand what we're gaining or losing by switching.

---Brett.


On Fri, Jun 1, 2012 at 11:36 AM, Stefan Frey <ste...@we...> wrote:
> Erik & Brett:
> taking the opportunity of a major update to Rails 2.0 I suggest to
> replace the log4j logging by the combination of sl4j and logback.
>
> See http://slf4j.org/ and http://logback.qos.ch/index.html for details.
>
> Any objections?
>
> Stefan
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Update of the logging framework

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

Erik & Brett:
taking the opportunity of a major update to Rails 2.0 I suggest to 
replace the log4j logging by the combination of sl4j and logback.

See http://slf4j.org/ and http://logback.qos.ch/index.html for details.

Any objections?

Stefan

Re: [Rails-devel] Revenue calculation performance

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

Mike:
your assumption that the calculation threads are not terminated 
correctly seems to be a good first try.

To turn of logging for the revenue calculation:

* If you have a working development setup simply change a line inside
log4j.properties (change from INFO to FATAL).

# log4j.logger.rails.algorithms=INFO
log4j.logger.rails.algorithms=FATAL

* If you use the latest release version:

Copy the attached logging file into the working directory of rails (that 
with the rails jar and rails.sh rails-bat) and start rails with this 
command:

java -Dlog4j.configuration="file:log4j_woa.properties" -jar rails-1.7.5.jar

Stefan

PS: If you can think about a good reuse of previous calculation results 
I would be glad to hear about your suggestions. I do not see how you are 
able to use any previous result if any detail has changed on either 
graph, trains running or special bonuses.

And keep in mind that the main run time stems from the brute-force 
search taking (after the revenue prediction cut-offs), the effort for 
the creation of the graph and all optimizations are neglectable.


On 05/31/2012 08:14 PM, Mike Bourke wrote:
> Saved Game: Will do. Nothing "blocks" the UI but it responds at the same
> slow pace as everything else, so the in-effect result is the same. Note that
> earlier in the game there is no problem. I have monitored the log file size
> as play proceeds and can state that the delays are roughly proportional to
> the size increase in the log file, though that may be nothing more than
> coincidence. I have also used task manager and can comment that the memory
> usage appears quite low; it's the cpu cycles that are maxing out.
>
> Stefan, from your description of how things are supposed to operate, I have
> a sudden suspicion that perhaps revenue calculation threads never terminate,
> each starting in a new thread parallel to the previous one. By the time you
> get to op round 9 or 10, you would then have hundreds of them running
> simultaneously.
>
> My idea for route calculation is similar to your caching of old solutions
> but several steps further developed. In essence it records all existing
> routes as they are created by tile lays and upgrading a tile also updates
> those calculations. Right now, the system recalculates route values from
> scratch each company's turn in each op round. That entails a lot of
> redundant calculation; my idea is an attempt to remove that redundancy by
> caching of possible runs. This would probably slow tile laying slightly in
> the early/mid-game, but should speed things up in the end game. I'll discuss
> that more fully some other time, preferring to deal with that as a separate
> issue, possibly even something to consider for version 3 (after version 2 is
> up and running, in other words) because it's a fairly fundamental change.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday, 1 June 2012 2:45 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Revenue calculation performance (was: An ongoing
> rails issue)
>
> Mike:
> those are the current options to prevent
>
> * To deactivate revenue calculation as a whole (all phases, complete
> game) choose the GameOption at the start of the game accordingly.
>
> * To avoid revenue calculation during the non-payout step use the
> Configuration Option in Panel "Map" =>  "Display Routes of active company".
>
> How the interface to the UI it is implemented (at least how it is supposed):
>
> * Revenue Calculation always runs in a separate thread and should never
> block the UI. If it does, it is a bug to be fixed.
>
> * During the Non-Payout steps it only shows the best route as hint (as
> request by John David Galt). You should always be able to select the
> next action and this itself should stop the current calculation and
> restart a new one based on the changed setting.
>
> * During the payout step it should provide intermediate best routes. As
> soon as you enter your own figure or choose distribution it should again
> stop calculation.
>
> Some more comments:
> * We had this discussion before (I remember your multiple Diesel 1830
> scenario). Same reply here that running two Diesels on an open map is a
> pretty hard scenario (even for a human player).
>
> * 1835 can be special case as well if the PR has three trains running
> (especially e.g. a 5+5, 6+6, 6+6), as the PR has many tokens so a pretty
> open map for PR too. However it should not be possible to have
> a multiple Diesel scenario in 1835.
>
> * Logging should not be an issue (in principle), but one could check
> that too. Logging can be switched by changing the log properties I will
> send you an adjusted one tomorrow for testing.
>
> * Improving the performance after reloading could also point to a java
> garbage collection issue or a problem with available memory on your
> system, however the revenue algorithm does not demand that much memory
> resources, but it could be something else in Rails which limits
> performance here.
>
> Potential improvements to revenue calculation are:
> * Dominating train heuristic (already implemented, will be merged into
> rails 2.0):
> This avoids calculating the same routes where the two Diesels simply
> swap their routes. Or e.g. that for a 6+6 and 5+5 combination, the 6+6
> will always run the longer route than the 5+5. For two diesels this cuts
> the running time nearly in half, for three trains there can be up to a
> six-fold speed increase.
>
> * Caching old solutions (not yet implemented, will come into rails 2.0
> branch soon):
> If the same network is run by identical trains the previous optimal run
> will be taken from cache. This will especially speed up undo/redo activity.
>
> * Design and implement a Maximum-Flow algorithm (not yet started, so
> nothing to expect soon):
> Create a different graph which allows to use a maximum flow algorithm to
> calculate the optimal runs (like John Tamplin reportedly did years ago).
> However this will only cover games with standard trains and no dynamic
> bonuses or other complex features (so it should cover 1830, but I am not
> sure about 1835). This would improve speed drastically for those scenarios.
>
> So please do as discussed on the list already: Provide a rails file,
> which allows to test this on other machines and by the developers and
> this could help to figure out the reasons for the problematic
> performance behavior.
>
>
> Stefan
>
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120531-0, 31/05/2012
> Tested on: 1/06/2012 4:14:05 AM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties framework

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

Not counting towns/minors towards the train length is a train attribute 
and not a stop attribute. (countTown=yes/no).

On 06/01/2012 09:57 AM, Erik Vos wrote:
> Mike,
>
> 18EU does not have n+m trains, so 'minor' has a different meaning in 18EU
> than in 1835. Stefan has taken care of that.
>
> But of course, if it would help Stefan to make stop counting more generic,
> I'm more than willing to add another type.
> In this new framework that would be very easy to do.  I'd call such a new,
> do-not-count score type "free".
>
> Erik.
>
>
>> -----Original Message-----
>> From: Mike Bourke [mailto:com...@ip...]
>> Sent: Friday, June 01, 2012 5:28 AM
>> To: 'Development list for Rails: an 18xx game'
>> Subject: Re: [Rails-devel] Stop properties framework
>>
>> Just to point out, Erik, that in 18EU and a couple of other games, minor
> stops
>> (towns) do not count against the overall stop limit, surely this is
> another
>> score type to be accommodated?
>>
>> Mike Bourke
>> Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's
>> Amulet http://www.legaciescampaignsetting.com
>>
>>
>>
>>
>> ---
>> avast! Antivirus: Outbound message clean.
>> Virus Database (VPS): 120531-0, 31/05/2012 Tested on: 1/06/2012 1:28:05 PM
>> avast! - copyright (c) 1988-2012 AVAST Software.
>> http://www.avast.com
>>
>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
>> landscape has changed and how IT managers can respond. Discussions will
>> include endpoint security, mobile security and the latest in malware
> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties framework

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

Erik:
some quick comments see below.

My major proposed change is to rename the Access class to StopType and 
then have those defined in xml.
You can even hardcode some of them if you prefer that.

Each Stop would then link to the according StopType object.
Similar to what we have for TrainType.

The StopType attribute below would then be renamed to id or name and has 
no function other than that.

Stefan

On 06/01/2012 12:25 AM, Erik Vos wrote:
> Stefan (and possibly others),
>
> Sorry, this is long.  I intend to put an even longer version in the Wiki
> later on.
>
> I'm happy to report that I have made quite some progress with the new Stop
> properties framework, that was discussed a while ago.
> It's almost ready to be pushed, but I would first like to present its main
> aspects and reopen it for discussion.  I would like to publish it as a
> whole.
>
> This framework is intended to provide maximum flexibility in stop property
> configuration, on many levels. It is also intended to address the following
> requirements and bugs:
> - 1837: the need to assign different types to different stops with different
> properties on one mine tile.
> - 1835: the Berlin loop bug, also relevant to 18EU.  As discussed, Stefan's
> existing method is not maintainable.
> - 1837 (and other games): the requirement that certain trains may only
> access one stop of a given type (i.e. mine).
>
> Please note, that this framework only addresses the problems mentioned (and
> several others) in *configuring* such properties.  Currently, just one of
> these properties is being used by Stefan's route and revenue calculation
> code, so there is a lot more work to do to bridge our two worlds.  See the
> end of this message for more remarks on this aspect.

It is not only between Rails Game and Revenue Code we have to 
coordinate, but also between Rails1.x and Rails2.0 code.
I will port your changes forward to Rails2.0 as soon as Rails2.0 has 
stabilized, however I will then add the required code to support that 
directly into Rails2.0. I have no intention to back-port this code then 
to Rails1.x.


>
> The stop properties are now collected in a new class named Access.  The
> properties are unchanged from the previous situation, except that one new
> property has been added:
>
> - stopType (city, town, port, mine, pass etc.). The list of values is
> hardcoded, but easily extendable if needed.

Even if you do not follow my proposal above, stopType should be merely a 
label and there should not be code like if stopType.equals(...) then ...

>
> - runTo (can a train run to a certain station?).  Still unused.  It is
> intended to configure initial access restrictions like those of 1851
> Birmingham and 1835 Elsass-Lothringen.
>
> - runThrough (can a train run through a certain station?). Still unused.
> Probably useful for off-map areas, Goderich and other cases.
>
> - loop (can a train re-enter a hex visited before?). Still unused, and
> perhaps redundant.  It was intended to prevent the Paris/Berlin/Vienna loop
> problems in 18EU and 1835, but that issue can be equally well addressed by
> the trainMutexID, to be discussed below. 'loop' may still prove useful for
> 1860, where no train may re-enter ANY hex.

If required it seems to be better an game attribute or a train 
attribute. Or is there any game where this loop property is hex-specific?

>
> - score type: major or minor (e.g. for 1835 n+m trains and for the many
> games where towns do not count against the train size).  This is the only
> stop property already in use.  The new framework allows more fine-grained
> configuration.
>
> - trainMutexID (provisional name).  The value can be any string.  This stop
> property is new, and intends to replace the 'city name' that Stefan
> currently is using to prevent the Berlin (etc.) loops.  As discussed
> earlier, that solution is not well sustainable. Another potential use of
> trainMutexID is to address the rule in 1837 and 18VA that goods trains may
> hit only one mine station each.

Question is whether a trainMutexId is valid globally or per-hex/tile? 
See your own question below. Or make this variable and create an 
attribute for it.

>
> In principle, all stop properties can be defined per hex, per tile, per
> station, per stop type, or even globally, but several (pretty obvious)
> exceptions exist.
> The configuration levels are, in order of precedence:
>
>   1. Specific MapHex station (defined in Map.xml with 'station' value>  0).
>   2. Specific Tile station (defined in TileSet.xml with 'station' value>  0).
> For preprinted tiles (id<=0) only.
>   3. MapHex (defined in Map.xml with 'station' value absent or 0).
>   4. Tile (defined in TileSet.xml with 'station' value absent or 0).  For
> preprinted tiles (id<=0) only.
>   5. MapManager default per stop type (defined as default in Map.xml).
>   6. TileManager default per stop type (defined as default in TileSet.xml).
>   7. MapManager general default (defined in Map.xml).
>   8. TileManager general default (defined in TileSet.xml).
>   9. Generic default per stop-type (hardcoded).

>
> Any property still undefined on a certain level "falls through" to the next
> level.  It's probably preferable to define properties per hex rather than
> per tile, but (at least for preprinted tiles) both are possible.
>
> Both property parsing and the precedence "fall-through" mechanism are
> methods of class Access.  This refactoring has allowed to clean up some
> repetitive code in various classes.
>
> Comments per property:
>
> - stop type can only be defined on levels 1-4, as it is required further
> down. If still undefined after level 4, it is derived from the tile Station
> type.
> - runTo and runThrough: levels 1-8.
> - scoreType and trainMutexID: levels 1-6.
>
> I could only test the fall-through mechanism with scoreType, as that is the
> only item currently used by Stefan's code.  Testing was easy, by setting
> conflicting score type values ('major' and 'minor') on different levels for
> ports and villages in 18EU, and watching the displayed train routes.
>
> I have also tested trainMutexId, after (temporarily) changing lines 257 and
> 258 in NetworkVertex to call city.getTrainMutexID() instead of
> station.getCityName().
> This way, I could switch the Berlin loop allowance on and off.
>
> Stefan, I was wondering why your setting of city="B/V" for the Berlin/Vienna
> tiles in 18EU did prevent one-hex loopback, but not the Berlin-Vienna route.
> I guess you are doing this check per hex only.  If you could lift that
> restriction, and look at duplicate city names (or whatever) on all stops of
> a route, I think we would have a strong mechanism to achieve all kinds of
> train access limitations.

Easy answer: The current identifier used for the vertex sets is derived 
from the combination of the hex city attribute combined with the tile 
city attribute. This allows running from Berlin to Vienna.

>
> Configuring stop properties is done with the<Access>  XML tag, as follows
> 	<Access station="1" type="city" runTo="yes" runThrough="no"
> score="minor" trainMutexID="X"/>
> where all attributes are optional (and in this example all or most are
> redundant anyway).
> The<Access>  tag can be put inside<Tile>,<Hex>  or in the<Defaults>
> sections of Map.xml and TiIeSet.xml. Multiple occurrences are allowed.

>
> I have added stop types like "port", "mine", "halt", "pass", just in case.
> For instance, in 18EU I can now declare the port properties in Map.xml:
> <Defaults>
> 	<Access type="port" score="minor"/>
> </Defaults>
>
> If only a stop type needs be declared, a shortcut is possible by putting its
> definition inside the<Tile>  or<Hex>  tags.
> So, for the 18EU port of Amsterdam, we could have
> 	<Hex name="A4" value="10" tile="-800" orientation="0">
> 		<Access type="port"/>
> 	</Hex>
> but this can be merged to
> 	<Hex name="A4" type="port" value="10" tile="-800" orientation="0"/>
> BTW 'type="port"' has replaced the (completely unused) 'port="yes"' in
> 18EU/Map.xml.
>
> Whether or not this all will turn out to be useful remains an open question,
> because Stefan appears to have implemented some restrictions in ways that
> may not directly correlate with this framework.  So, to make it work, some
> bridge must be built somewhere.  I am also open to add<Access>  attributes
> that would directly call Stefan's classes, as I understand he has suggested,
> provided that the new attribute names are a bit user-friendly.  I am
> thinking of attributes like accessModifier and/or revenueModifier.  The
> latter may be needed anyway.

The current structure which I believe is quite reasonable is the 
following separates the revenue code from Rails code efficiently and 
there are only a few specialized classes which are translate the 
structure of Rails into the structure of revenue calculation:
Those are the two adapter classes and there are a few methods in 
NetworkTrain and NetworkVertex, but this could be moved into adapters as 
well) All other classes are ignorant to any changes of Rails and vice 
versa.
Game specific cooperation between Rails and the Revenue Calculator is 
done via the three modifier classes.

>
> Comments welcome.  No hurry.
>
> Erik.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties framework

[Mark S. <mar...@gm...>]

Erik,

I haven't been as active recently as in the past, but given this
discussion, have you considered the "Halts" and "Run through Tokened Out
Station" in 1860? Or have you considered the Mail Stops in 1853? With
regards to your thinking here?

There is of course the minor matter where 1853 has two (Broad/Metre)
different gauge trains and three (Broad, Metre and Dual) different gauge
tracks in Auto-Route Calculation?

Mark

On Fri, Jun 1, 2012 at 3:57 AM, Erik Vos <eri...@xs...> wrote:

> Mike,
>
> 18EU does not have n+m trains, so 'minor' has a different meaning in 18EU
> than in 1835. Stefan has taken care of that.
>
> But of course, if it would help Stefan to make stop counting more generic,
> I'm more than willing to add another type.
> In this new framework that would be very easy to do.  I'd call such a new,
> do-not-count score type "free".
>
> Erik.
>
>
> > -----Original Message-----
> > From: Mike Bourke [mailto:com...@ip...]
> > Sent: Friday, June 01, 2012 5:28 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Stop properties framework
> >
> > Just to point out, Erik, that in 18EU and a couple of other games, minor
> stops
> > (towns) do not count against the overall stop limit, surely this is
> another
> > score type to be accommodated?
> >
> > Mike Bourke
> > Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's
> > Amulet http://www.legaciescampaignsetting.com
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Outbound message clean.
> > Virus Database (VPS): 120531-0, 31/05/2012 Tested on: 1/06/2012 1:28:05
> PM
> > avast! - copyright (c) 1988-2012 AVAST Software.
> > http://www.avast.com
> >
> >
> >
> >
> >
>
> ----------------------------------------------------------------------------
> --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and threat
> > landscape has changed and how IT managers can respond. Discussions will
> > include endpoint security, mobile security and the latest in malware
> threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Stop properties framework

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

Mike,

18EU does not have n+m trains, so 'minor' has a different meaning in 18EU
than in 1835. Stefan has taken care of that. 

But of course, if it would help Stefan to make stop counting more generic,
I'm more than willing to add another type.  
In this new framework that would be very easy to do.  I'd call such a new,
do-not-count score type "free".

Erik.


> -----Original Message-----
> From: Mike Bourke [mailto:com...@ip...]
> Sent: Friday, June 01, 2012 5:28 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Stop properties framework
> 
> Just to point out, Erik, that in 18EU and a couple of other games, minor
stops
> (towns) do not count against the overall stop limit, surely this is
another
> score type to be accommodated?
> 
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's
> Amulet http://www.legaciescampaignsetting.com
> 
> 
> 
> 
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120531-0, 31/05/2012 Tested on: 1/06/2012 1:28:05 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties framework

[Mike B. <com...@ip...>]

Just to point out, Erik, that in 18EU and a couple of other games, minor
stops (towns) do not count against the overall stop limit, surely this is
another score type to be accommodated?

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com




---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120531-0, 31/05/2012
Tested on: 1/06/2012 1:28:05 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

[Rails-devel] Stop properties framework

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

Stefan (and possibly others),

Sorry, this is long.  I intend to put an even longer version in the Wiki
later on.

I'm happy to report that I have made quite some progress with the new Stop
properties framework, that was discussed a while ago.
It's almost ready to be pushed, but I would first like to present its main
aspects and reopen it for discussion.  I would like to publish it as a
whole.

This framework is intended to provide maximum flexibility in stop property
configuration, on many levels. It is also intended to address the following
requirements and bugs:
- 1837: the need to assign different types to different stops with different
properties on one mine tile.
- 1835: the Berlin loop bug, also relevant to 18EU.  As discussed, Stefan's
existing method is not maintainable.
- 1837 (and other games): the requirement that certain trains may only
access one stop of a given type (i.e. mine). 

Please note, that this framework only addresses the problems mentioned (and
several others) in *configuring* such properties.  Currently, just one of
these properties is being used by Stefan's route and revenue calculation
code, so there is a lot more work to do to bridge our two worlds.  See the
end of this message for more remarks on this aspect.

The stop properties are now collected in a new class named Access.  The
properties are unchanged from the previous situation, except that one new
property has been added:

- stopType (city, town, port, mine, pass etc.). The list of values is
hardcoded, but easily extendable if needed.

- runTo (can a train run to a certain station?).  Still unused.  It is
intended to configure initial access restrictions like those of 1851
Birmingham and 1835 Elsass-Lothringen.

- runThrough (can a train run through a certain station?). Still unused.
Probably useful for off-map areas, Goderich and other cases.

- loop (can a train re-enter a hex visited before?). Still unused, and
perhaps redundant.  It was intended to prevent the Paris/Berlin/Vienna loop
problems in 18EU and 1835, but that issue can be equally well addressed by
the trainMutexID, to be discussed below. 'loop' may still prove useful for
1860, where no train may re-enter ANY hex. 

- score type: major or minor (e.g. for 1835 n+m trains and for the many
games where towns do not count against the train size).  This is the only
stop property already in use.  The new framework allows more fine-grained
configuration.

- trainMutexID (provisional name).  The value can be any string.  This stop
property is new, and intends to replace the 'city name' that Stefan
currently is using to prevent the Berlin (etc.) loops.  As discussed
earlier, that solution is not well sustainable. Another potential use of
trainMutexID is to address the rule in 1837 and 18VA that goods trains may
hit only one mine station each.

In principle, all stop properties can be defined per hex, per tile, per
station, per stop type, or even globally, but several (pretty obvious)
exceptions exist.
The configuration levels are, in order of precedence:

 1. Specific MapHex station (defined in Map.xml with 'station' value > 0).
 2. Specific Tile station (defined in TileSet.xml with 'station' value > 0).
For preprinted tiles (id<=0) only.
 3. MapHex (defined in Map.xml with 'station' value absent or 0).
 4. Tile (defined in TileSet.xml with 'station' value absent or 0).  For
preprinted tiles (id<=0) only.
 5. MapManager default per stop type (defined as default in Map.xml).
 6. TileManager default per stop type (defined as default in TileSet.xml).
 7. MapManager general default (defined in Map.xml).
 8. TileManager general default (defined in TileSet.xml).
 9. Generic default per stop-type (hardcoded).

Any property still undefined on a certain level "falls through" to the next
level.  It's probably preferable to define properties per hex rather than
per tile, but (at least for preprinted tiles) both are possible.

Both property parsing and the precedence "fall-through" mechanism are
methods of class Access.  This refactoring has allowed to clean up some
repetitive code in various classes.

Comments per property:

- stop type can only be defined on levels 1-4, as it is required further
down. If still undefined after level 4, it is derived from the tile Station
type.  
- runTo and runThrough: levels 1-8.
- scoreType and trainMutexID: levels 1-6.

I could only test the fall-through mechanism with scoreType, as that is the
only item currently used by Stefan's code.  Testing was easy, by setting
conflicting score type values ('major' and 'minor') on different levels for
ports and villages in 18EU, and watching the displayed train routes.

I have also tested trainMutexId, after (temporarily) changing lines 257 and
258 in NetworkVertex to call city.getTrainMutexID() instead of
station.getCityName().
This way, I could switch the Berlin loop allowance on and off.

Stefan, I was wondering why your setting of city="B/V" for the Berlin/Vienna
tiles in 18EU did prevent one-hex loopback, but not the Berlin-Vienna route.
I guess you are doing this check per hex only.  If you could lift that
restriction, and look at duplicate city names (or whatever) on all stops of
a route, I think we would have a strong mechanism to achieve all kinds of
train access limitations.

Configuring stop properties is done with the <Access> XML tag, as follows 
	<Access station="1" type="city" runTo="yes" runThrough="no"
score="minor" trainMutexID="X"/>
where all attributes are optional (and in this example all or most are
redundant anyway).  
The <Access> tag can be put inside <Tile>, <Hex> or in the <Defaults>
sections of Map.xml and TiIeSet.xml. Multiple occurrences are allowed.

I have added stop types like "port", "mine", "halt", "pass", just in case.
For instance, in 18EU I can now declare the port properties in Map.xml:
<Defaults>
	<Access type="port" score="minor"/>
</Defaults>

If only a stop type needs be declared, a shortcut is possible by putting its
definition inside the <Tile> or <Hex> tags.
So, for the 18EU port of Amsterdam, we could have
	<Hex name="A4" value="10" tile="-800" orientation="0">
		<Access type="port"/>
	</Hex>
but this can be merged to 
	<Hex name="A4" type="port" value="10" tile="-800" orientation="0"/>
BTW 'type="port"' has replaced the (completely unused) 'port="yes"' in
18EU/Map.xml.

Whether or not this all will turn out to be useful remains an open question,
because Stefan appears to have implemented some restrictions in ways that
may not directly correlate with this framework.  So, to make it work, some
bridge must be built somewhere.  I am also open to add <Access> attributes
that would directly call Stefan's classes, as I understand he has suggested,
provided that the new attribute names are a bit user-friendly.  I am
thinking of attributes like accessModifier and/or revenueModifier.  The
latter may be needed anyway.

Comments welcome.  No hurry.

Erik.

Re: [Rails-devel] Revenue calculation performance (was: An ongoing rails issue)

[Mike B. <com...@ip...>]

Saved Game: Will do. Nothing "blocks" the UI but it responds at the same
slow pace as everything else, so the in-effect result is the same. Note that
earlier in the game there is no problem. I have monitored the log file size
as play proceeds and can state that the delays are roughly proportional to
the size increase in the log file, though that may be nothing more than
coincidence. I have also used task manager and can comment that the memory
usage appears quite low; it's the cpu cycles that are maxing out.

Stefan, from your description of how things are supposed to operate, I have
a sudden suspicion that perhaps revenue calculation threads never terminate,
each starting in a new thread parallel to the previous one. By the time you
get to op round 9 or 10, you would then have hundreds of them running
simultaneously.

My idea for route calculation is similar to your caching of old solutions
but several steps further developed. In essence it records all existing
routes as they are created by tile lays and upgrading a tile also updates
those calculations. Right now, the system recalculates route values from
scratch each company's turn in each op round. That entails a lot of
redundant calculation; my idea is an attempt to remove that redundancy by
caching of possible runs. This would probably slow tile laying slightly in
the early/mid-game, but should speed things up in the end game. I'll discuss
that more fully some other time, preferring to deal with that as a separate
issue, possibly even something to consider for version 3 (after version 2 is
up and running, in other words) because it's a fairly fundamental change.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Friday, 1 June 2012 2:45 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Revenue calculation performance (was: An ongoing
rails issue)

Mike:
those are the current options to prevent

* To deactivate revenue calculation as a whole (all phases, complete 
game) choose the GameOption at the start of the game accordingly.

* To avoid revenue calculation during the non-payout step use the 
Configuration Option in Panel "Map" => "Display Routes of active company".

How the interface to the UI it is implemented (at least how it is supposed):

* Revenue Calculation always runs in a separate thread and should never 
block the UI. If it does, it is a bug to be fixed.

* During the Non-Payout steps it only shows the best route as hint (as 
request by John David Galt). You should always be able to select the 
next action and this itself should stop the current calculation and 
restart a new one based on the changed setting.

* During the payout step it should provide intermediate best routes. As 
soon as you enter your own figure or choose distribution it should again 
stop calculation.

Some more comments:
* We had this discussion before (I remember your multiple Diesel 1830 
scenario). Same reply here that running two Diesels on an open map is a 
pretty hard scenario (even for a human player).

* 1835 can be special case as well if the PR has three trains running 
(especially e.g. a 5+5, 6+6, 6+6), as the PR has many tokens so a pretty 
open map for PR too. However it should not be possible to have
a multiple Diesel scenario in 1835.

* Logging should not be an issue (in principle), but one could check 
that too. Logging can be switched by changing the log properties I will 
send you an adjusted one tomorrow for testing.

* Improving the performance after reloading could also point to a java 
garbage collection issue or a problem with available memory on your 
system, however the revenue algorithm does not demand that much memory 
resources, but it could be something else in Rails which limits 
performance here.

Potential improvements to revenue calculation are:
* Dominating train heuristic (already implemented, will be merged into 
rails 2.0):
This avoids calculating the same routes where the two Diesels simply 
swap their routes. Or e.g. that for a 6+6 and 5+5 combination, the 6+6 
will always run the longer route than the 5+5. For two diesels this cuts 
the running time nearly in half, for three trains there can be up to a 
six-fold speed increase.

* Caching old solutions (not yet implemented, will come into rails 2.0 
branch soon):
If the same network is run by identical trains the previous optimal run 
will be taken from cache. This will especially speed up undo/redo activity.

* Design and implement a Maximum-Flow algorithm (not yet started, so 
nothing to expect soon):
Create a different graph which allows to use a maximum flow algorithm to 
calculate the optimal runs (like John Tamplin reportedly did years ago). 
However this will only cover games with standard trains and no dynamic 
bonuses or other complex features (so it should cover 1830, but I am not 
sure about 1835). This would improve speed drastically for those scenarios.

So please do as discussed on the list already: Provide a rails file, 
which allows to test this on other machines and by the developers and 
this could help to figure out the reasons for the problematic 
performance behavior.


Stefan





---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120531-0, 31/05/2012
Tested on: 1/06/2012 4:14:05 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Revenue calculation performance (was: An ongoing rails issue)

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

Mike:
those are the current options to prevent

* To deactivate revenue calculation as a whole (all phases, complete 
game) choose the GameOption at the start of the game accordingly.

* To avoid revenue calculation during the non-payout step use the 
Configuration Option in Panel "Map" => "Display Routes of active company".

How the interface to the UI it is implemented (at least how it is supposed):

* Revenue Calculation always runs in a separate thread and should never 
block the UI. If it does, it is a bug to be fixed.

* During the Non-Payout steps it only shows the best route as hint (as 
request by John David Galt). You should always be able to select the 
next action and this itself should stop the current calculation and 
restart a new one based on the changed setting.

* During the payout step it should provide intermediate best routes. As 
soon as you enter your own figure or choose distribution it should again 
stop calculation.

Some more comments:
* We had this discussion before (I remember your multiple Diesel 1830 
scenario). Same reply here that running two Diesels on an open map is a 
pretty hard scenario (even for a human player).

* 1835 can be special case as well if the PR has three trains running 
(especially e.g. a 5+5, 6+6, 6+6), as the PR has many tokens so a pretty 
open map for PR too. However it should not be possible to have
a multiple Diesel scenario in 1835.

* Logging should not be an issue (in principle), but one could check 
that too. Logging can be switched by changing the log properties I will 
send you an adjusted one tomorrow for testing.

* Improving the performance after reloading could also point to a java 
garbage collection issue or a problem with available memory on your 
system, however the revenue algorithm does not demand that much memory 
resources, but it could be something else in Rails which limits 
performance here.

Potential improvements to revenue calculation are:
* Dominating train heuristic (already implemented, will be merged into 
rails 2.0):
This avoids calculating the same routes where the two Diesels simply 
swap their routes. Or e.g. that for a 6+6 and 5+5 combination, the 6+6 
will always run the longer route than the 5+5. For two diesels this cuts 
the running time nearly in half, for three trains there can be up to a 
six-fold speed increase.

* Caching old solutions (not yet implemented, will come into rails 2.0 
branch soon):
If the same network is run by identical trains the previous optimal run 
will be taken from cache. This will especially speed up undo/redo activity.

* Design and implement a Maximum-Flow algorithm (not yet started, so 
nothing to expect soon):
Create a different graph which allows to use a maximum flow algorithm to 
calculate the optimal runs (like John Tamplin reportedly did years ago). 
However this will only cover games with standard trains and no dynamic 
bonuses or other complex features (so it should cover 1830, but I am not 
sure about 1835). This would improve speed drastically for those scenarios.

So please do as discussed on the list already: Provide a rails file, 
which allows to test this on other machines and by the developers and 
this could help to figure out the reasons for the problematic 
performance behavior.


Stefan


On 05/31/2012 10:50 AM, Mike Bourke wrote:
> This is not a bug per se, but it's something that needs to be mentioned, and
> even improved or resolved before rails can be offered as fully functional to
> the public.
>
> Rails 1.7.x becomes deadly slow towards the end of a game. In today's game,
> I clicked on "no token" for the second-last turn in the last op round and
> had to wait more than five minutes (closer to eight) before the game
> progressed to calculating the revenue for that particular company. 1835 is
> especially bad in this respect because of the potential for a company to
> have multiple diesels, and is almost unplayable as a result.
>
> Note that this problem occurs with ALL actions in an op round. A company
> starts its turn. Click on a hex on the map to indicate where you want to lay
> a tile, wait five-to-ten minutes. The available tiles are offered, click on
> one, wait 5-10 minutes. The tile is then laid, click on it to rotate it
> until correct facing is achieved - wait another 5-10 minutes before the
> first rotation takes effect. Click on "lay tile", wait another 5-10 minutes
> before the game progresses to tokens. Click on a tile to lay a token, wait
> for 5-10 minutes before the option to lay a token in that space is
> displayed. Click on the lay token button, or on the no token button, wait
> another 5-10 minutes before revenue calculations start. Wait up to an hour
> for revenue calculations to be complete (or wait at least 5-10 minutes for a
> value that's close if not equal to the final revenue valuation to be
> achieved) and click Set Revenue, wait 5-10 minutes before being given the
> option of how to distribute that revenue. Click one of the buttons and wait
> another 5-10 minutes for the option to buy trains (if applicable). And so
> on. Clicking on "game" on the game status window menu produces another wait
> of 5-10 minutes before the menu is displayed. Clicking save game produces a
> wait of 5-20 minutes before the save game window appears. Clicking save does
> nothing for another 5-10 minutes.
>
> All this appears to be due to the game consuming 100% available CPU and
> wanting more.
>
> It's understandable that as brown tiles becomes available and the variety
> and length of possible routes increases, it takes longer to determine the
> optimum route. Nevertheless, this all seems excessive, and should have no
> impact on actions like "save game".
>
> I have found that the problem can be reduced (not eliminated) temporarily by
> saving the game, closing rails, and then reopening it, so it appears in part
> to be a problem with the size of the log file (which is always smaller after
> doing so than it was), but this is not the whole issue by any means.
>
> My system is relatively slow by modern standards - only 2.65GHz -
> exacerbating the problem. In combination with the "loading a saved game"
> improvement mentioned a moment ago, I suspect that this is the reason no
> players have noticed / complained about the problem in past testing.
>
> To assess the true scale of the issue, would it be possible to include an
> option to turn logging off in the game setup panel for 1.7.6? I can
> understand why logging in general is both desirable and comprehensive while
> the game is still in a beta-testing mode, but I think this needs further
> investigation. SOMETHING is happening repeatedly in all those CPU cycles
> that bogs the whole game down to a slow crawl.
>
> I also have some thoughts on an alternative top-level process for handling
> revenue calculations but they *might* not yield any improvement (might even
> be worse) and have a wishlist for functionality enhancements, but they are
> unimportant in comparison to this issue.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120530-1, 31/05/2012
> Tested on: 31/05/2012 6:50:43 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] An ongoing rails issue

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

On 31 May 2012 16:40, Mike Bourke <com...@ip...> wrote:
> 2Gb of RAM (it's
> currently maxed out) while newer computers can handle more?

Yeech, that might do it, I didn't even think it was possible to run XP
on less than 4GB of RAM, I've certainly never attempted it!

Testing user experiences from a common save file on different
configurations seems like a worthwhile exercise to try and get samples
from the user community, I've got at least 4 machines of different
configurations I could test with

Phil

Re: [Rails-devel] An ongoing rails issue

[Mike B. <com...@ip...>]

I have the latest version of Java as of 8:05 AM this morning, but it sounds
like others have not seen a serious problem in this area. The question
therefore becomes, how typical is my experience? How many others will have
problems of this sort in the future? Is it a problem with WinXP vs later
operating systems? Is it because my hardware can only hold 2Gb of RAM (it's
currently maxed out) while newer computers can handle more?

Erik, Logging is definitely a part of the problem (or reloading a saved game
would not speed up the processing of a turn). But it's unclear how much of a
contribution it is making, which is why I was asking for the temporary
inclusion of a no-logging option.

I can see how "having rails think for me" could be a significant factor in
calculating routes, but don't see how that applies to opening the game save
menu and similar actions.

I propose a test: I will save a late game and then load the saved game. I
will then time exactly how long it takes to perform various actions over the
next operating round. By attaching both saved game and the times to a reply,
I will establish a set of benchmarks. Other people can then load the saved
game and repeat those actions under a variety of conditions. This should
reduce the number of variables involved.

I mention this because I have observed a difference in playing style between
what I and my friends use and that employed by other people - in essence, we
are more cooperative with the tile lays and rail heads and more vicious in
the stock rounds while others are more prone to blocking routes with rail
heads. This difference may be exacerbating or hiding the situation, and
hence would need to be eliminated before meaningful comparisons can be made.
A common saved game would be the easiest way to do so that I can think of.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: Bill Rosgen [mailto:ro...@gm...] 
Sent: Friday, 1 June 2012 1:08 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] An ongoing rails issue

I have seen rails take several minutes to calculate routes, but it was
optimizing multiple diesels for the CGR at the end of an 1856 game.  It's
possible to generate a lot of potential paths if there are a couple of
parallel lines with many crosses between them.  This was back when
route-calulation was done only once per turn, so it was somewhat bearable.

Bill

On 2012-05-31, at 22:55 , Phil Davies wrote:

> I personally have never experienced a performance issue in rails, at
> worst I've seen it take maybe 30 seconds to calculate a route, and
> that was running Diesels on a highly open 1856 map.  Is this
> potentially a JVM issue?  Tried a newer version of Java?
> 
> Also, could this be an issue of other software/memory utilisation?
> 2.56 Ghz isn't that old, I'm surprised it's performing that poorly
> 
> On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
>> Are other people experiencing the same problem?
>> 
>> --
>> Chris
>> 
>> Please consider the environment before printing this e-mail.
>> 
>> 
>> 
>> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke
<com...@ip...>
>> wrote:
>>> 
>>> This is not a bug per se, but it's something that needs to be mentioned,
>>> and
>>> even improved or resolved before rails can be offered as fully
functional
>>> to
>>> the public.
>>> 
>>> Rails 1.7.x becomes deadly slow towards the end of a game. In today's
>>> game,
>>> I clicked on "no token" for the second-last turn in the last op round
and
>>> had to wait more than five minutes (closer to eight) before the game
>>> progressed to calculating the revenue for that particular company. 1835
is
>>> especially bad in this respect because of the potential for a company to
>>> have multiple diesels, and is almost unplayable as a result.
>>> 
>>> Note that this problem occurs with ALL actions in an op round. A company
>>> starts its turn. Click on a hex on the map to indicate where you want to
>>> lay
>>> a tile, wait five-to-ten minutes. The available tiles are offered, click
>>> on
>>> one, wait 5-10 minutes. The tile is then laid, click on it to rotate it
>>> until correct facing is achieved - wait another 5-10 minutes before the
>>> first rotation takes effect. Click on "lay tile", wait another 5-10
>>> minutes
>>> before the game progresses to tokens. Click on a tile to lay a token,
wait
>>> for 5-10 minutes before the option to lay a token in that space is
>>> displayed. Click on the lay token button, or on the no token button,
wait
>>> another 5-10 minutes before revenue calculations start. Wait up to an
hour
>>> for revenue calculations to be complete (or wait at least 5-10 minutes
for
>>> a
>>> value that's close if not equal to the final revenue valuation to be
>>> achieved) and click Set Revenue, wait 5-10 minutes before being given
the
>>> option of how to distribute that revenue. Click one of the buttons and
>>> wait
>>> another 5-10 minutes for the option to buy trains (if applicable). And
so
>>> on. Clicking on "game" on the game status window menu produces another
>>> wait
>>> of 5-10 minutes before the menu is displayed. Clicking save game
produces
>>> a
>>> wait of 5-20 minutes before the save game window appears. Clicking save
>>> does
>>> nothing for another 5-10 minutes.
>>> 
>>> All this appears to be due to the game consuming 100% available CPU and
>>> wanting more.
>>> 
>>> It's understandable that as brown tiles becomes available and the
variety
>>> and length of possible routes increases, it takes longer to determine
the
>>> optimum route. Nevertheless, this all seems excessive, and should have
no
>>> impact on actions like "save game".
>>> 
>>> I have found that the problem can be reduced (not eliminated)
temporarily
>>> by
>>> saving the game, closing rails, and then reopening it, so it appears in
>>> part
>>> to be a problem with the size of the log file (which is always smaller
>>> after
>>> doing so than it was), but this is not the whole issue by any means.
>>> 
>>> My system is relatively slow by modern standards - only 2.65GHz -
>>> exacerbating the problem. In combination with the "loading a saved game"
>>> improvement mentioned a moment ago, I suspect that this is the reason no
>>> players have noticed / complained about the problem in past testing.
>>> 
>>> To assess the true scale of the issue, would it be possible to include
an
>>> option to turn logging off in the game setup panel for 1.7.6? I can
>>> understand why logging in general is both desirable and comprehensive
>>> while
>>> the game is still in a beta-testing mode, but I think this needs further
>>> investigation. SOMETHING is happening repeatedly in all those CPU cycles
>>> that bogs the whole game down to a slow crawl.
>>> 
>>> I also have some thoughts on an alternative top-level process for
handling
>>> revenue calculations but they *might* not yield any improvement (might
>>> even
>>> be worse) and have a wishlist for functionality enhancements, but they
are
>>> unimportant in comparison to this issue.
>>> 
>>> Mike Bourke
>>> Campaign Mastery http://www.campaignmastery.com
>>> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>>> 
>>> 
>>> 
>>> 
>>> ---
>>> avast! Antivirus: Outbound message clean.
>>> Virus Database (VPS): 120530-1, 31/05/2012
>>> Tested on: 31/05/2012 6:50:43 PM
>>> avast! - copyright (c) 1988-2012 AVAST Software.
>>> http://www.avast.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
----------------------------------------------------------------------------
--
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
Discussions
>>> will include endpoint security, mobile security and the latest in
malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
>> 
>> 
>>
----------------------------------------------------------------------------
--
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


----------------------------------------------------------------------------
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120530-1, 31/05/2012
Tested on: 1/06/2012 1:40:43 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] An ongoing rails issue

[Bill R. <ro...@gm...>]

I have seen rails take several minutes to calculate routes, but it was optimizing multiple diesels for the CGR at the end of an 1856 game.  It's possible to generate a lot of potential paths if there are a couple of parallel lines with many crosses between them.  This was back when route-calulation was done only once per turn, so it was somewhat bearable.

Bill

On 2012-05-31, at 22:55 , Phil Davies wrote:

> I personally have never experienced a performance issue in rails, at
> worst I've seen it take maybe 30 seconds to calculate a route, and
> that was running Diesels on a highly open 1856 map.  Is this
> potentially a JVM issue?  Tried a newer version of Java?
> 
> Also, could this be an issue of other software/memory utilisation?
> 2.56 Ghz isn't that old, I'm surprised it's performing that poorly
> 
> On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
>> Are other people experiencing the same problem?
>> 
>> --
>> Chris
>> 
>> Please consider the environment before printing this e-mail.
>> 
>> 
>> 
>> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke <com...@ip...>
>> wrote:
>>> 
>>> This is not a bug per se, but it's something that needs to be mentioned,
>>> and
>>> even improved or resolved before rails can be offered as fully functional
>>> to
>>> the public.
>>> 
>>> Rails 1.7.x becomes deadly slow towards the end of a game. In today's
>>> game,
>>> I clicked on "no token" for the second-last turn in the last op round and
>>> had to wait more than five minutes (closer to eight) before the game
>>> progressed to calculating the revenue for that particular company. 1835 is
>>> especially bad in this respect because of the potential for a company to
>>> have multiple diesels, and is almost unplayable as a result.
>>> 
>>> Note that this problem occurs with ALL actions in an op round. A company
>>> starts its turn. Click on a hex on the map to indicate where you want to
>>> lay
>>> a tile, wait five-to-ten minutes. The available tiles are offered, click
>>> on
>>> one, wait 5-10 minutes. The tile is then laid, click on it to rotate it
>>> until correct facing is achieved - wait another 5-10 minutes before the
>>> first rotation takes effect. Click on "lay tile", wait another 5-10
>>> minutes
>>> before the game progresses to tokens. Click on a tile to lay a token, wait
>>> for 5-10 minutes before the option to lay a token in that space is
>>> displayed. Click on the lay token button, or on the no token button, wait
>>> another 5-10 minutes before revenue calculations start. Wait up to an hour
>>> for revenue calculations to be complete (or wait at least 5-10 minutes for
>>> a
>>> value that's close if not equal to the final revenue valuation to be
>>> achieved) and click Set Revenue, wait 5-10 minutes before being given the
>>> option of how to distribute that revenue. Click one of the buttons and
>>> wait
>>> another 5-10 minutes for the option to buy trains (if applicable). And so
>>> on. Clicking on "game" on the game status window menu produces another
>>> wait
>>> of 5-10 minutes before the menu is displayed. Clicking save game produces
>>> a
>>> wait of 5-20 minutes before the save game window appears. Clicking save
>>> does
>>> nothing for another 5-10 minutes.
>>> 
>>> All this appears to be due to the game consuming 100% available CPU and
>>> wanting more.
>>> 
>>> It's understandable that as brown tiles becomes available and the variety
>>> and length of possible routes increases, it takes longer to determine the
>>> optimum route. Nevertheless, this all seems excessive, and should have no
>>> impact on actions like "save game".
>>> 
>>> I have found that the problem can be reduced (not eliminated) temporarily
>>> by
>>> saving the game, closing rails, and then reopening it, so it appears in
>>> part
>>> to be a problem with the size of the log file (which is always smaller
>>> after
>>> doing so than it was), but this is not the whole issue by any means.
>>> 
>>> My system is relatively slow by modern standards - only 2.65GHz -
>>> exacerbating the problem. In combination with the "loading a saved game"
>>> improvement mentioned a moment ago, I suspect that this is the reason no
>>> players have noticed / complained about the problem in past testing.
>>> 
>>> To assess the true scale of the issue, would it be possible to include an
>>> option to turn logging off in the game setup panel for 1.7.6? I can
>>> understand why logging in general is both desirable and comprehensive
>>> while
>>> the game is still in a beta-testing mode, but I think this needs further
>>> investigation. SOMETHING is happening repeatedly in all those CPU cycles
>>> that bogs the whole game down to a slow crawl.
>>> 
>>> I also have some thoughts on an alternative top-level process for handling
>>> revenue calculations but they *might* not yield any improvement (might
>>> even
>>> be worse) and have a wishlist for functionality enhancements, but they are
>>> unimportant in comparison to this issue.
>>> 
>>> Mike Bourke
>>> Campaign Mastery http://www.campaignmastery.com
>>> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>>> 
>>> 
>>> 
>>> 
>>> ---
>>> avast! Antivirus: Outbound message clean.
>>> Virus Database (VPS): 120530-1, 31/05/2012
>>> Tested on: 31/05/2012 6:50:43 PM
>>> avast! - copyright (c) 1988-2012 AVAST Software.
>>> http://www.avast.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] An ongoing rails issue

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

I personally have never experienced a performance issue in rails, at
worst I've seen it take maybe 30 seconds to calculate a route, and
that was running Diesels on a highly open 1856 map.  Is this
potentially a JVM issue?  Tried a newer version of Java?

Also, could this be an issue of other software/memory utilisation?
2.56 Ghz isn't that old, I'm surprised it's performing that poorly

On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
> Are other people experiencing the same problem?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke <com...@ip...>
> wrote:
>>
>> This is not a bug per se, but it's something that needs to be mentioned,
>> and
>> even improved or resolved before rails can be offered as fully functional
>> to
>> the public.
>>
>> Rails 1.7.x becomes deadly slow towards the end of a game. In today's
>> game,
>> I clicked on "no token" for the second-last turn in the last op round and
>> had to wait more than five minutes (closer to eight) before the game
>> progressed to calculating the revenue for that particular company. 1835 is
>> especially bad in this respect because of the potential for a company to
>> have multiple diesels, and is almost unplayable as a result.
>>
>> Note that this problem occurs with ALL actions in an op round. A company
>> starts its turn. Click on a hex on the map to indicate where you want to
>> lay
>> a tile, wait five-to-ten minutes. The available tiles are offered, click
>> on
>> one, wait 5-10 minutes. The tile is then laid, click on it to rotate it
>> until correct facing is achieved - wait another 5-10 minutes before the
>> first rotation takes effect. Click on "lay tile", wait another 5-10
>> minutes
>> before the game progresses to tokens. Click on a tile to lay a token, wait
>> for 5-10 minutes before the option to lay a token in that space is
>> displayed. Click on the lay token button, or on the no token button, wait
>> another 5-10 minutes before revenue calculations start. Wait up to an hour
>> for revenue calculations to be complete (or wait at least 5-10 minutes for
>> a
>> value that's close if not equal to the final revenue valuation to be
>> achieved) and click Set Revenue, wait 5-10 minutes before being given the
>> option of how to distribute that revenue. Click one of the buttons and
>> wait
>> another 5-10 minutes for the option to buy trains (if applicable). And so
>> on. Clicking on "game" on the game status window menu produces another
>> wait
>> of 5-10 minutes before the menu is displayed. Clicking save game produces
>> a
>> wait of 5-20 minutes before the save game window appears. Clicking save
>> does
>> nothing for another 5-10 minutes.
>>
>> All this appears to be due to the game consuming 100% available CPU and
>> wanting more.
>>
>> It's understandable that as brown tiles becomes available and the variety
>> and length of possible routes increases, it takes longer to determine the
>> optimum route. Nevertheless, this all seems excessive, and should have no
>> impact on actions like "save game".
>>
>> I have found that the problem can be reduced (not eliminated) temporarily
>> by
>> saving the game, closing rails, and then reopening it, so it appears in
>> part
>> to be a problem with the size of the log file (which is always smaller
>> after
>> doing so than it was), but this is not the whole issue by any means.
>>
>> My system is relatively slow by modern standards - only 2.65GHz -
>> exacerbating the problem. In combination with the "loading a saved game"
>> improvement mentioned a moment ago, I suspect that this is the reason no
>> players have noticed / complained about the problem in past testing.
>>
>> To assess the true scale of the issue, would it be possible to include an
>> option to turn logging off in the game setup panel for 1.7.6? I can
>> understand why logging in general is both desirable and comprehensive
>> while
>> the game is still in a beta-testing mode, but I think this needs further
>> investigation. SOMETHING is happening repeatedly in all those CPU cycles
>> that bogs the whole game down to a slow crawl.
>>
>> I also have some thoughts on an alternative top-level process for handling
>> revenue calculations but they *might* not yield any improvement (might
>> even
>> be worse) and have a wishlist for functionality enhancements, but they are
>> unimportant in comparison to this issue.
>>
>> Mike Bourke
>> Campaign Mastery http://www.campaignmastery.com
>> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>>
>>
>>
>>
>> ---
>> avast! Antivirus: Outbound message clean.
>> Virus Database (VPS): 120530-1, 31/05/2012
>> Tested on: 31/05/2012 6:50:43 PM
>> avast! - copyright (c) 1988-2012 AVAST Software.
>> http://www.avast.com
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>