rails-devel — List for discussion of Rails development

Re: [Rails-devel] Stop properties

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

Brett & Erik,
maybe a new release should be done this weekend to have all the new games out 
for testing during Erik's vacation?
Stefan


> 
> Ok, this all should be doable, hopefully before I'm going on vacation next
> week Wednesday for almost three weeks.  During my vacation you probably
> won't hear from me.
> 
> Erik.
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

Erik,

> I think I have not added any setters yet, but I have already mentioned that
> we might need some. In cases like 1851 Birmingham, runTo is in fact
> phase-dependent (although you have probably already solved that with some
> modifier).

Yes that is a GraphModifier that removes Birmingham  from the graph in the 
phases required.

The runTo modifier is a generalization of that (except that it is not phase-
dependent).

> 
> I know, but I had hoped that you would like to add it (apologies for not
> asking so explicitly).
> 
> It's all in the spirit of giving more power to the non-programmers amongst
> us.  Several people have already started implementing games by preparing
> XML, only to find that they have to involve you and me to get the details
> done.  I'm very well aware that we cannot make everything configurable in
> XML, and that it would be silly to strive for it.  But why not do it for
> simple settings that occur relatively frequently?  I thought 'loop' would
> be such a case, and pretty easy to implement (but I cannot really judge
> that).

I am aware and support of other people adding games ;-)
The two important words above are "simple" and/or "frequently". 

However quite often it seems that two games share the same mechanism (most of 
the time because they use the same terminology), but they are substantially 
different in mechanism: For example unfortunately it is not enough to add an 
attribute " merge='yes' " to companies to allow them merging...

So the 1860 example cannot be easily solved by adding the attributes. The 
short explanation is that currently all simple track that only connects the 
scoring vertices are optimized away. It is possible to protect vertices from 
that (for similar cases), however I do not like the idea to protect all track 
vertices as it could be a drag on the revenue calculation, especially as 1860 
has some other rules to consider. So let us wait until we implement that game.

> 
> We also have cases like 18EU Paris/Berlin/Vienna, where I already have
> added loop="no". If you have no plan to start supporting it soon, my
> hopeful loop settings should indeed be removed.

I forgot about that case: If only scoring vertices are meant this is possible.
Maybe we should call this scoreTwice = "no" as it avoids people from thinking 
this is identical to loop (revisit twice).

This would replace the current identical name mechanism. 
However we would still need a mechanism to prevent scoring multiple-hex 
offboard areas twice. I am not sure how you would like to implement that?

I think an off-board area attributes (name, values etc.) should be defined 
only once and then have a list of hexes it refers to.
Then this object could be used directly to create the vertexVisitSet that I 
currently have to create for the algorithm.
But it makes the setup of the hexes harder, but I believe that is the correct 
solution. I could volunteer to implement that.

Stefan

Re: [Rails-devel] Patch: getName() in parser.GameOption and C&O Home in 1830-Reading

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

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> 
> In the first case, it seems that when calling GameOption.getName() the
> returned string is "null" for any option that is not a parametrized option
(i.e.
> pretty much anything that isn't UnlimitedTopTrains).  This seems to happen
> because at least as far back as commit dd14df the getName() function
> returns the string parametrizedName, which is only non-null for
> parametrized options.   The attached patch fixes this by adding an
explicit
> check to test if parametrizedName is null, returning the regular name if
it is.
> I'm not sure if this is the best way to fix this, but it seems to work.

The intention was to have parametrizedName equal to name in the absence of
parameters, but indeed that is not the case in the Game setup phase
(probably since Brett has refactored that - but the bug in GameOption is
mine). I'll have another look at that, but for now I'll accept your fix.

Erik.

Re: [Rails-devel] Stop properties

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, August 15, 2011 6:25 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> Erik:
> I tried to change my coding in NetworkVertex accordingly.
> Thanks a lot this will simplify the previous code needed to adapt the
revenue
> code to the algorithm code substantially.
> 
> However as usual with coding one realizes some more thing.
> 
> I think having those attributes are one thing, checking if runThrough or
runTo
> is possible still requires more than that.
> 
> The best solution would be adding additional methods for if a runThrough
> and a runTo is possible for a specific company. Thus it also checks the
current
> token situation.
> 
> Thus something like
> 
> public boolean runThroughAllowedFor(PublicCompanyI company) public
> boolean runToAllowedFor(PublicCompanyI company)

Hmm, that does make sense.  

> >From my perspective you could then define the
> isRunToAllowed/isRunThroughAllowed for  as private or even remove it, as
> this is only required internally. Similar for the according methods in
MapHex
> or Tile, they only need to be package private and not public.

On the supposition that we will never subclass MapHex, Stop and Tile. But
that's indeed unlikely.
 
> Even better would be if  you could add similar methods. Then all values
are
> retrieved from the stop object, instead of sometimes querying hex or
station
> instead.
> 
> * public int getValueAt(PhaseI phase)
> Retrieves the current value (either from the related station for
cities/towns
> or via the MapHex for offboard defined values)
> 
> * public String getName()
> Retrieves the name: Either from the hex or if undefined there from the
> related station.
> 
> Again this would allow to restrict access/visibility of a lot of related
methods
> in Stop / Station / MapHex.

I think getName() must be public everywhere - it's used in many ways. 

Ok, this all should be doable, hopefully before I'm going on vacation next
week Wednesday for almost three weeks.  During my vacation you probably
won't hear from me.

Erik.

Re: [Rails-devel] Stop properties

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

> * Are you sure that the time of calling initStopProperties that all other
> objects are already setup correctly? 

That should be OK: this method is called via finishConfiguration(), i.e.
after all XML has been parsed (that is a hard rule).

> And you should ensure that it is not
> possible to change the values of the runTo and runThrough attributes of
hex
> and station after creation of the stop objects, otherwise there could be
nasty
> surprises, if someone tries this in the future. 

I think I have not added any setters yet, but I have already mentioned that
we might need some. In cases like 1851 Birmingham, runTo is in fact
phase-dependent (although you have probably already solved that with some
modifier).

> The alternative is to go
> through the list of attributes each time the methods are called.

Sounds unnecessary to me.

> * I currently do not support the loop attribute. 

I know, but I had hoped that you would like to add it (apologies for not
asking so explicitly). 

It's all in the spirit of giving more power to the non-programmers amongst
us.  Several people have already started implementing games by preparing
XML, only to find that they have to involve you and me to get the details
done.  I'm very well aware that we cannot make everything configurable in
XML, and that it would be silly to strive for it.  But why not do it for
simple settings that occur relatively frequently?  I thought 'loop' would be
such a case, and pretty easy to implement (but I cannot really judge that).

We also have cases like 18EU Paris/Berlin/Vienna, where I already have added
loop="no". If you have no plan to start supporting it soon, my hopeful loop
settings should indeed be removed. 

Erik.

Re: [Rails-devel] Patch: getName() in parser.GameOption and C&O Home in 1830-Reading

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

Bill, 

Eclipse/Egit cannot load git patches, so for the time being I slightly
prefer 'normal' patches.
Git patches also work , but I have to load these from the command line.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Monday, August 15, 2011 9:15 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Patch: getName() in parser.GameOption and C&O
> Home in 1830-Reading
> 
> In the current development version I encounter two problems:
> 
> 1) When creating a new game, the options (such as 1830 Variants) are
> ignored.
> 
> 2) In 1830-Reading, the C&O has no home.
> 
> In the first case, it seems that when calling GameOption.getName() the
> returned string is "null" for any option that is not a parametrized option
(i.e.
> pretty much anything that isn't UnlimitedTopTrains).  This seems to happen
> because at least as far back as commit dd14df the getName() function
> returns the string parametrizedName, which is only non-null for
> parametrized options.   The attached patch fixes this by adding an
explicit
> check to test if parametrizedName is null, returning the regular name if
it is.
> I'm not sure if this is the best way to fix this, but it seems to work.
> 
> The second problem seems to be a simple omission of 'Reading' from the
list
> of options when the C&O's home is specified.  The attached patch adds
> 'Reading' to the list of options for which the C&O's home appears in the
usual
> place.
> 
> I've attached what I think is an "Eclipse format" patch.  If you'd rather
have a
> "git format" patch, let me know: I can produce those too.
> 
> Bill

Re: [Rails-devel] Stop properties

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

Erik:
I tried to change my coding in NetworkVertex accordingly.
Thanks a lot this will simplify the previous code needed to adapt the revenue 
code to the algorithm code substantially.

However as usual with coding one realizes some more thing.

I think having those attributes are one thing, checking if runThrough or runTo 
is possible still requires more than that.

The best solution would be adding additional methods for if a runThrough and a 
runTo is possible for a specific company. Thus it also checks the current 
token situation.

Thus something like

public boolean runThroughAllowedFor(PublicCompanyI company)
public boolean runToAllowedFor(PublicCompanyI company)

From my perspective you could then define the 
isRunToAllowed/isRunThroughAllowed for  as private or even remove it, as this 
is only required internally. Similar for the according methods in MapHex or 
Tile, they only need to be package private and not public.

Even better would be if  you could add similar methods. Then all values are 
retrieved from the stop object, instead of sometimes querying hex or station 
instead.

* public int getValueAt(PhaseI phase)
Retrieves the current value (either from the related station for cities/towns 
or via the MapHex for offboard defined values)

* public String getName()
Retrieves the name: Either from the hex or if undefined there from the related 
station.

Again this would allow to restrict access/visibility of a lot of related 
methods in Stop / Station / MapHex.


Some other remarks:

* Are you sure that the time of calling initStopProperties that all other 
objects are already setup correctly? And you should ensure that it is not 
possible to change the values of the runTo and runThrough attributes of hex 
and station after creation of the stop objects, otherwise there could be nasty 
surprises, if someone tries this in the future. The alternative is to go 
through the list of attributes each time the methods are called.

* I currently do not support the loop attribute. The 1825 not scoring twice 
rule is supported by an independent revenue modifier.
1860 has so many strange rules that it surely needs modifier(s), thus there is 
no need for such an attribute now. I suggest to remove or comment it out, as 
long as it not supported (again to avoid surprise).

Stefan


On Friday, August 12, 2011 02:47:02 pm Erik Vos wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
> 
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)
> Q3. See point 6: some algorithms classes currently pick up values from
> HexMap.  The current code requires that these values should be taken from
> Stop (see comments below).  Would that be OK for you?  Or should I add
> methods to HexMap and/or Tile that honour defaults?
> 
> Here is the overview (I'll put it into the wiki later):
> 
> 1. City has been renamed to Stop. This object represents a train stop on a
> certain tile that has been laid on a certain hex.
> Stop will become the primary source of all properties that are required to
> define routes and calculate revenues.
> (I have left Station as it is, because this object name equates to the
> corresponding tag names in Tile.xml,
> which I did not want to change after all.  I hope we can live with this
> slight naming inconsistency.)
> 
> 2. The Stop properties can be derived from either MapHex (defined in
> Map.xml) or Tile (defined in TileSet.xml).
> If both exist, MapHex takes precedence, as it is more specific.
> If neither is defined, it will use defaults on the Manager level in the
> same XML files, with the same precedence.
> See item 5 for details and a precedence list.
> 
> 3. The stop properties are:
> 
> - type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
> I have added offmap because usually different defaults apply.
> However, for train running purposes offmap stops should normally be treated
> as major cities.
> Cities on "red" tiles are marked offmap by default.
> "null" applies to plain track tiles, and allows to define a non-default
> "loop" value (1860), see below.
> 
> - runTo = {no|yes|tokenOnly}. Default "yes".
> "no" would apply to e.g. Birmingham in 1851 before phase 4 and
> Elsaß-Lothringen in 1835 except in phase 2.
> "tokenOnly" would apply to e.g. the 18Scan red cities.
> This usage implies that the runTo value may be phase-dependent.
> 
> - runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
> "yes" obviously only applies if the city is not closed (i.e. filled by
> tokens of other companies).
> "no" would apply to standard off-map areas,
> "tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
> Is there a need for "always" (i.e., even if closed)? Any other special
> cases?
> 
> 4. A somewhat related new MapHex property (also accessible to Stop, but not
> restricted to tiles with stops) is:
> - loop = {yes|no}, which defines if one train may touch a hex more than
> once.  Default "yes" (exception: offmap "no").
> "no" applies to *all* tiles in 1860.
> 
> 5. Defaults per stop type, and generic defaults (type=null) can be defined
> in Map.xml and TileSet.xml.
> These defaults are parsed and stored in MapManager and TileManager,
> respectively.
> The precedence is (the first non-null value found is used):
> - specific Hex
> - specific Tile
> - Hex default per stop type
> - Tile default per stop type
> - generic Hex default (type=null)
> - generic Tile default (type = null)
> - final default as defined above.
> 
> I believe this all gives enough flexibility, but of course the proof of the
> pudding is in the eating.
> I have tested settings at various but not all levels.  Current usage
> effectively only needs the first and last level.
> 
> 6. Stop, Tile and MapHex all have these four methods:
> Stop.Type getType() or getStopType(),
> Stop.RunTo isRunToAllowed(),
> Stop.RunThrough isRunThroughAllowed(),
> Stop.Loop isLoopAllowed().
> However, only the return values from Stop follow the precedence rules. The
> values from HexMap and Tile only return any *explicit* settings in <Hex>
> and <Tile>, so these are of little use.
> Please let me know if that could be a problem for some use cases.  I would
> have to add separate methods if these return values should also honour the
> defaults.
> 
> (Note: the existing HexMap.Run type has been split and moved to Stop.  The
> algorithms classes still pick up values from HexMap, which is no longer
> correct, see above.)
> 
> I have so far added explicit settings to the following cases (all in
> Map.xml):
> 1830: The PRR [and Reading] bases: runThrough="tokenOnly".
> 1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
> tile -939 already behaves correctly, but that one has been manually
> tweaked).
> 18EU Paris/Berlin/Vienna: loop="no".
> 
> The Stop code temporarily logs all Stop settings in a way that stands out,
> so that checking the effects of any trial settings should be easy.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Patch: getName() in parser.GameOption and C&O Home in 1830-Reading

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

It turns out to be easier than I thought to produce git format patches: I've attached such a patch in case it is the preferred format.  Apologies for the double post.

Bill Rosgen

[Rails-devel] Patch: getName() in parser.GameOption and C&O Home in 1830-Reading

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

In the current development version I encounter two problems:

1) When creating a new game, the options (such as 1830 Variants) are ignored.

2) In 1830-Reading, the C&O has no home.

In the first case, it seems that when calling GameOption.getName() the returned string is "null" for any option that is not a parametrized option (i.e. pretty much anything that isn't UnlimitedTopTrains).  This seems to happen because at least as far back as commit dd14df the getName() function returns the string parametrizedName, which is only non-null for parametrized options.   The attached patch fixes this by adding an explicit check to test if parametrizedName is null, returning the regular name if it is.  I'm not sure if this is the best way to fix this, but it seems to work.

The second problem seems to be a simple omission of 'Reading' from the list of options when the C&O's home is specified.  The attached patch adds 'Reading' to the list of options for which the C&O's home appears in the usual place.

I've attached what I think is an "Eclipse format" patch.  If you'd rather have a "git format" patch, let me know: I can produce those too.

Bill

Re: [Rails-devel] Stop properties

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

Erik:
your suggestions/questions below all belong to the same discussion.

My design principle for the revenue calculation is the following:

A) Implement the general 18xx rules in the core revenue classes in a general 
way (thus allow variations) and keep performance in mind. 

B) Implement all specific game rules in specific modifiers, which only 
implement what is needed. Here I do not take care about performance.
All modifiers have to use pre-defined interfaces.

This translates to XML: 
A) All variations of the core rules should be controlled by variables in XML.

B) Define specific settings (e.g. hexes, trains) inside the modifier classes. 
No XML needed.

It has the additional benefit to keep the XML clean and focused.

It might happen over time that a rule upgrades from the specific to the 
general category.

This was my type A) remark, type B) remarks below ;-)

Stefan


On Sunday, August 14, 2011 03:21:15 pm Erik Vos wrote:
> > > Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts
> > > (see also Q7 below)?
> > 
> > I would only add stopTypes to XML which are already supported.
> > So currently we have only city, town and offmap.
> 
> We have already started to work at 18VA and 1825, so I would like to look
> at these games anyway.
> 
> After all, the stop properties are only intended to make your life a bit
> easier, at least in this matter....:-)

For me the stopType is nothing more than a name (for me). I do not like to 
have something like stopType.equals ("....") inside the core code (type A)). 
This is similar to the name of a trainType: All attributes have to be defined 
by attributes, the name does not matter.

This for example enables the fact that entities with identical names behave 
differently across games (think about how 2-trains in 18EU or 1830, H-trains 
in 1844 or 1826 etc.).

> 
> > I have not checked how you defined the ports in 18EU, but for me they are
> > identical to towns and would not need an own stopType.
> 
> That's true for 18EU, and 1841 as well (except that in 1841 ports do not
> count as stops in finding a valid route - towns do).
> Currently, 18EU ports are defined as towns.

Again it does not matter: If the type is only a name, one can define 18EU 
ports as ports and then define the attributes identical to towns in 18EU.

> 
> 18VA ports are of a different kind. These are not separate stops (for
> finding valid route purposes), but add a bonus to the nearby cities (if
> tokened) - but only if that city is at one end of a route.
> To enforce port cities being at the end of a route, it could be helpful to
> add ports as special kind of stops anyway. (This only applies to Baltimore
> and Annapolis: you cannot both run through to Philadelphia or Baltimore and
> get the port bonus).
> On the other hand, if we don't consider 18VA ports as separate entities, I
> think we should also remove the 18VA ports from the visible map.

As the type is only a name, ports in 18EU are independent of ports in 18VA.
However it seems that this is a very specific behavior, thus it will be a 
modifier => type B) rule, no XML support.

> 
> > Towns can and should always be minor as for standard trains major and
> > minor stops are both counted to train reach.
> 
> OK.


To be more precise: Actually towns could be defined as major in 1830 as there 
are no +-trains currently. However as soon as someones adds a plus-train, 
(s)he would be surprised that it does not behave as expected.


> 
> > All 1825 specific issues are supported by revenue modifiers already, thus
> > there does not need a XML support for this.
> > 
> > 1825 modifiers are:
> > DoubleHeadingModifier to allow two 2-trains run as a 3 train.
> > ScoreTileOnlyOnceModifier to check that each tile is scored only once.
> > TerminateAtMajorModifier to only allow runs that start/finish at majors.
> 
> Wouldn't you need something extra to support 1825 halts (on tile #11, in
> some kits)?
> Only T-trains may (optionally) consider halts as stops, other trains must
> ignore halts.
> I think a separate scoreType could be helpful here, but perhaps you can do
> without.

You are right, but I thought that T-trains and tile #11 only exists in some 
kits, I did not know that they are already included.
Again sounds like a modifier, thus no need to support inside XML.

> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] GameManager and players array problem (Java implementation of reordering players)

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

Martin,

 

I have fixed current player highlighting in the StatusWindow. I have not changed the player order (which I understand is what you really want), because that is not so easy to do.  I may work on that later.

 

I also will look at the StartRoundWindow later. One aspect I want to think about is if it’s right to sell the privates and the investors in the same StartRound, or that that round can better be split.

 

I’m not sure what you wanted me to do with your patch; I have not put it into the repository (yet).

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Friday, August 12, 2011 9:22 PM
To: Development list for Rails: an 18xx game; Erik Vos
Subject: Re: [Rails-devel] GameManager and players array problem (Java implementation of reordering players)

 

 Hi Erik, et al.

 

heres the patch coming up :)

 

The "bug", rather the problem with StatusWindow and StartRoundWindow can be repeated as following:

 

Generate a Game, bid for the Privates like usual and after the last private has found its owner, the code internally reorders the player order.

That is yet not reflected on the StartRoundWindow it simply sets the operational marker to the Player in the first Slot but of course doesnt update the Caption nor the Tableau on StartRoundWindow.

 

If you then proceed to buy an Investor that investor gets credited to the correct Player in StatusWindow. So assume Player A B C D, then Player A (always) will have the first Choice of the Investor even though internally it might be Player D( as he has spent the most money in Privates).

Player A gets shown selects an Investor and that is credited to Player D.

 

But here comes the problem, looking during the execution of the Program into the variables at a breakpoint of UpdateStatus in StartRoundWindow i couldnt find the changed players array in there, just the original players array with order [A,B,C,D] while it should have been [D,B,A,C] for example, based on the cash spent in StartRound....

 

Dont hesitate to contact me, if anything is still unclear :)

 

Regards,

Martin

 

 

-----Original-Nachricht-----

Subject: Re: [Rails-devel] GameManager and players array problem (Java implementation of reordering players)

Date: Fri, 12 Aug 2011 15:49:48 +0200

From: "Erik Vos" <eri...@xs...>

To: "'Development list for Rails: an 18xx game'" <rai...@li...>

 

 

Hi Martin,

 

It is one thing that the UI player order does not change; that is a presentation question.

But it is another thing if cash or share movements affect the wrong players, at least as it is shown in the UI. That would be a bug.

 

It is well possible that the effects of the changed player order have not yet been fully worked out, but to look into that I need an example.

Do you have a saved file that I can run against the current code and that shows the bug?  

If I need any of your new code to show this bug, you could send me a patch. In the new Git environment I can easily create a local branch that does not affect the central repository.

 

(I have one 1880 saved file from you, but it doesn’t load because it appears to require a class rails.game.specific._1880.StockMarket_1880 that I don’t have.)

 

Erik. 

 

From: Dr. Martin Brumm [mailto:dr....@t-...] 
Sent: Friday, August 12, 2011 7:30 AM
To: Rails Developer Liste
Subject: [Rails-devel] GameManager and players array problem (Java implementation of reordering players)

 

Hi Brett, Erik and Stefan et al. 

 

For the background information, 

 

1880 and a number of other games change the seat order after the starting or in the starting round based on certain auction results.

 

Eric helped me to bring in a reorder routine in rails.game.gamemanager called reorderPlayerByCash which should reorder the players array based on their wallet.

 

This seems to function well inside the scope of the Roundclass and its subclasses. 

 

But to my astonishment or Javanewbeeness the changed array players doesn’t show in the gameManager itself if you watch the array in debug mode outside of the Roundclasses (i.e. rails.ui.swing.startwindow and Statuswindow). So naturally the changed playerorder cant be accessed from that classes and thus the changed seating order doesn’t reflect it self in the ui. Whereas the actions taken in the rounds are nevertheless credited right in the ui display. This leads in a Stockround to the funny actions that Player A is shown as active and upon acting his action leads to result for player C for example.

 

So if anyone of you could point me at the silly simple (I assume) mistake in my train of thought in implementing  the reordering I would be very grateful.

 

Regards,

Martin

 

 

Re: [Rails-devel] Stop properties

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

OK, I have pushed the Stop properties code, after wrapping it up with
Stefan's latest comments.

ScoreType (minor, major) has been added.  See 1830/Map.xml for the <Access>
XML format; this also applies to TileSet.xml.

StopTypes have been restricted to city, town, offmap, although I expect that
more types will be needed later on.

Erik.

Re: [Rails-devel] Stop properties

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

> > Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts
> > (see also Q7 below)?
> >
> I would only add stopTypes to XML which are already supported.
> So currently we have only city, town and offmap.

We have already started to work at 18VA and 1825, so I would like to look at
these games anyway.

After all, the stop properties are only intended to make your life a bit
easier, at least in this matter....:-)

> I have not checked how you defined the ports in 18EU, but for me they are
> identical to towns and would not need an own stopType.

That's true for 18EU, and 1841 as well (except that in 1841 ports do not
count as stops in finding a valid route - towns do).
Currently, 18EU ports are defined as towns.

18VA ports are of a different kind. These are not separate stops (for
finding valid route purposes), but add a bonus to the nearby cities (if
tokened) - but only if that city is at one end of a route. 
To enforce port cities being at the end of a route, it could be helpful to
add ports as special kind of stops anyway. (This only applies to Baltimore
and Annapolis: you cannot both run through to Philadelphia or Baltimore and
get the port bonus).
On the other hand, if we don't consider 18VA ports as separate entities, I
think we should also remove the 18VA ports from the visible map.

> Towns can and should always be minor as for standard trains major and
> minor stops are both counted to train reach.

OK.

> All 1825 specific issues are supported by revenue modifiers already, thus
> there does not need a XML support for this.
> 
> 1825 modifiers are:
> DoubleHeadingModifier to allow two 2-trains run as a 3 train.
> ScoreTileOnlyOnceModifier to check that each tile is scored only once.
> TerminateAtMajorModifier to only allow runs that start/finish at majors.

Wouldn't you need something extra to support 1825 halts (on tile #11, in
some kits)? 
Only T-trains may (optionally) consider halts as stops, other trains must
ignore halts.
I think a separate scoreType could be helpful here, but perhaps you can do
without.

Erik.

Re: [Rails-devel] Stop properties

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

Erik,
answers see below.
Stefan

> Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts (see
> also Q7 below)?
> 
> I think each stopType needs a default scoreType, as follows:
 > 
> stopType =
> {city(major)|town(major*)|offmap(major)|halt(minor?)|pass(major)|port(minor
> )
> 
> |mine(major)} .

I would only add stopTypes to XML which are already supported. 
So currently we have only city, town and offmap.
I have not checked how you defined the ports in 18EU, but for me they are 
identical to towns and would not need an own stopType.

> 
> * Q5: or minor? I chose 'major' because 1830 and many other games there is
> no difference between cities and towns as regards scoring, but OTOH the
> train properties and I believe your code can already deal with either.

Towns can and should always be minor as for standard trains major and minor 
stops are both counted to train reach.

The revenue calculation supports trains that
* ignore minors (as express trains)
* score minors, but do not count them to reach (as trains in 18EU)
* multiply majors and/or minors (as 4D in 18AL)
* plus trains (as 3+3 in 1835)
* hex trains (in 1826)

Each train is defined individually, thus all types of train can run jointly.

> 
> Some other issues:
> 
> Q6: How are we going to deal with train-dependent runTo values, as we have
> in 1837 (mines) and 18VA (CMDs), where only G-trains may run from/to such
> stops?

This should be supported by a RevenueDynamicModifier, as the current algorithm 
does not support this out of the box. All modifiers can be setup as 
configurable components in XML, thus you could and should add attributes 
there, placed under RevenueManager.

> 
> Q7: In 1825, the only difference between cities and towns is, that routes
> may not start or end at a town (except for some special trains).
> We could implement this by setting <Access stopType="town" runTo="no"/>,
> but I don't know if that would work, and it would be train-dependent too.
> Does runThrough="yes" require runTo="yes", or are these two settings
> entirely independent?

All 1825 specific issues are supported by revenue modifiers already, thus 
there does not need a XML support for this.

1825 modifiers are:
DoubleHeadingModifier to allow two 2-trains run as a 3 train.
ScoreTileOnlyOnceModifier to check that each tile is scored only once.
TerminateAtMajorModifier to only allow runs that start/finish at majors.

I would only add XML support if we have a lot more games that would make use 
of it. And then I would start adding attributes to configure the modifiers (if 
required), instead to change the general xml settings.

The advantage for a modifier is that we commit only to work correctly in the 
context of the specific game for which it is defined.

For properties defined in general xml, it should work in general and in 
combination with all other settings of all other properties defined in the 
xml. And this is difficult to code and especially test against.

Re: [Rails-devel] Stop properties

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

Stefan,

Revised proposals and some further questions below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> The only issue I have is related to the type attribute:
> 
> Could you please add another attribute that defines if the stop has to be
> counted against the major or minor train reach? Maybe call this
revenueType
> or scoreType? Values are {major|minor}. Or rename the type attribute to
> name and call that type.

Very good point.  I had mixed up stopType and scoreType.  

For stopTypes we can now reuse the original 'city' and 'town' markers:
stopType = {city|town|offmap|halt|pass|port|mine|null} 
Note: I have removed 'medium', as it does not affect scoring, only
upgrading.
(The special upgrading rules for medium cities in 1854 and 1880 can already
be dealt with. 
Perhaps the upgrade rules could be simplified by adding a special <Hex>
attribute to mark *hexes* as medium cities).

scoreType = {major|minor}.
Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts (see
also Q7 below)?

I think each stopType needs a default scoreType, as follows:

stopType =
{city(major)|town(major*)|offmap(major)|halt(minor?)|pass(major)|port(minor)
|mine(major)} .
* Q5: or minor? I chose 'major' because 1830 and many other games there is
no difference between cities and towns as regards scoring, but OTOH the
train properties and I believe your code can already deal with either.

Some other issues:

Q6: How are we going to deal with train-dependent runTo values, as we have
in 1837 (mines) and 18VA (CMDs), where only G-trains may run from/to such
stops?

Q7: In 1825, the only difference between cities and towns is, that routes
may not start or end at a town (except for some special trains). 
We could implement this by setting <Access stopType="town" runTo="no"/>, but
I don't know if that would work, and it would be train-dependent too.
Does runThrough="yes" require runTo="yes", or are these two settings
entirely independent?

Erik.

Re: [Rails-devel] Current implementation, branch Rails 2.0?

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

Erik:
just a comment on your thoughts and a short summary of my current plans:

I understand that the issue how various classes can interact with each other 
has to be solved and needs consideration. 

However the solution to put everything very close together is similar to solve 
such problems by making all variables global.

I am currently sketching/designing a proposal/possibility to break up the 
round classes and still allowing classes to interact in a disciplined way:

My solution will be to store such information in an abstraction called 
context, which allows to store objects that implement a contextItem interface. 
That includes for example information about the current phase, the active 
player, the operating company, the available colors etc.

I will split the round classes into two separate parts: First a replacement 
for the round mechanism, that defines the progression between players (for 
share rounds) or companies (for operating rounds).

And then the sub-phases inside a round will all get separate classes called 
activities. So there will be a LayTileActivity, a LayTokenActivity, a 
BuyTrainActivity etc. for the OperatingRound. They provide and execute actions 
similar to the Correction managers.

All of this should be configurable using a Round.xml file, which will allow to 
define not only the activities used, but also the sequence of those. For this 
all activities will get a slot that allows to assign ActivationStrategies to 
decouple the activity  (especially for those activities that only occur after 
specific events etc.)

Finally the RoundManager asks the current active Round which Activities are 
there, checks if they are active currently by calling their 
ActivationStrategies, allows the Round classes to add additional information 
to the current context which is then passed to the active Activities. Based on 
the context the activities create the actions. The RoundManager collects the 
actions and forwards them to the UI. Given the selected action the 
RoundManager then returns it to the according Activity class object.

I will hope to come up with a prototype implementation of the new framework 
soon, as working code is usually more convincing than lots of words.

Stefan


On Friday, August 12, 2011 05:21:25 pm Erik Vos wrote:
> Hi Stefan,
> 
> I agree with 100% of what you are saying, but there is one implicit
> presumption: that we can avoid side effects.  And that isn't generally
> true.
> 
> Take your alternative proposal to handle phase actions (or triggers - I
> don't like that word either, but that aside).
> Now the Phase tries to reach the action taker by calling a stub, that call
> is passed on and must in some Round subclass be implemented with actual
> code.
> You propose a register-and-call-back approach, which is fine, if only the
> action taker can access the registration point. Getting access is the
> central problem; read on.
> 
> There is quite some history before I arrived at the current architecture.
> Originally I tried to follow the let-each-object-mind-its-own-business
> approach (following the original OO paradigm), which led to a situation
> where many different objects (portfolios, public companies etc.) were
> executing various parts of particular action types.
> This worked in simple cases, but as more features got implemented, more
> side-effects cropped up, where code in various objects needed to call
> methods in different, sometimes remote objects.  So the question arose how
> an object can get access to another object to which it doesn't have a
> direct reference.
> 
> Initially this was often done via static methods calls.  But I had to
> abandon that approach as I realised that it would inhibit foreseen future
> developments.
> 
> Mainly in the last two years I found myself following two paths:
> 1. Move code out of the objects into the Round classes, which have easier
> access to other objects via the GameManager.  You will not believe it, but
> in my perception these moves have much simplified and clarified the
> affected code parts.
> 2. Pass down references to the various managers (including GameManager),
> usually via the ubiquitous finishConfiguration methods, which are
> specifically intended to create any required relationships after all XML
> has been parsed.
> 
> There transitions aren't complete, but now that we have most OR code in the
> OR class, it has become much easier to add new or override existing
> behaviour.  And about every object is now reachable from there.
> 
> The situation has become much more complex with the advent of
> rounds-within-rounds in 1856, 1835 and 18EU.  In 1835, Prussian formation
> rounds even run inside company turns.  It took a while before I had arrived
> at a workable approach to make this happen.
> 
> Now I'm facing your proposal to fragment the OR class into an untold number
> of separate classes.  Your example of the correction classes is
> instructive, and I regret that I have not looked at and learned from your
> code in an earlier stage. But correction is a very simple case, out of the
> game as it were, with just one item being affected without side effects. 
> Fine.  But I'm far from convinced that it will look equally nice if we are
> going to apply this concept to real game actions, with all required side
> effects, and that it really will simplify rather than even more complicate
> the code.
> 
> You certainly have set my thoughts in motion, and I'm open to be convinced
> by more realistic examples.  But I hope you'll understand that I have no
> great desire to set myself to start reworking these central concepts once
> again.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, August 11, 2011 10:38 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Current implementation, branch Rails 2.0?
> > 
> > > All fine, but so what?  Is size bad per se?
> > 
> > Erik,
> > No certainly not. All this is not about good or bad. In one sense the
> > size shows the thoughts and efforts for all details you have put into
> > those
> 
> classes.
> 
> > It is the other way around: As I do not have the time and the memory to
> > understand all thoughts and conditions you considered, that created that
> > code, I would prefer to digest all that in little portions.
> > 
> > Organizing code into classes allows to review only the relevant classes
> 
> that
> 
> > you need know. It is like organizing stuff into little boxes where you
> > put labels on the boxes what is inside. This makes it much easier to
> > find
> 
> things
> 
> > and to understand the big picture: Maybe like in a big department store:
> It is
> 
> > much easier to get an overview by studying the directory of the store
> 
> instead
> 
> > of searching every shelf.
> > 
> > An object orientated languages allows storing pieces of code in classes
> 
> and if
> 
> > I want rewrite/change/add something to a class, I have to make sure that
> > after my changes everything works as before. If the class is small, it is
> 
> easier
> 
> > to check if I do not introduce side effects and I only have to test the
> 
> part
> 
> > where the class is responsible for: So take the example for the
> > OperatingRound. If I change anything inside I have to test all
> 
> functionality
> 
> > which is managed by the OperatingRound. Thus I change something related
> > to token lay, it can potentially have side effects on tile laying,
> > revenue payouts, train buying, loans etc.
> > 
> > If the token lay code is inside in a separate class it is impossible to
> 
> effect the
> 
> > other functionality of OperatingRound.
> > 
> > I had the issue more than a year ago: I started adding the NoMap
> > functionalities which in principle should only change Tile and Token Lay.
> > However due to side effects of my (at that time bad understanding) of the
> > step mechanism inside the OperatingRound I broke the 1856 loan
> > mechanism.
> > And I was not even aware of that code as this code was part of a subclass
> 
> of
> 
> > OperatingRound.
> > 
> > The same issue about the size of classes effects writing unit tests: For
> > refactoring the best is to have the class covered fully by unit tests. If
> 
> you
> 
> > have two small classes instead of one large you can start refactoring
> 
> earlier
> 
> > than you had to write all tests first.
> > 
> > And the other good thing is, that with smaller classes it is less likely
> 
> that two
> 
> > people work at the same time on the same class, thus it makes merging and
> > potential merge conflicts less likely.
> > 
> > For my daily job I have to deal with large programs in non-object
> 
> orientated
> 
> > languages and even there I prefer to split problems into smaller,
> > independent pieces. Especially if you come back to those programs several
> > years later, it makes it much easier to enhance or fix something.
> > 
> > OK enough text, but it is not about fashionable or good/bad, it is simply
> > about making coding easier and so increase the fun part of it.
> > 
> > Stefan
> > 
> > ´
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> > administration capabilities and model configuration. Take the hassle out
> 
> of
> 
> > deploying and managing Subversion and the tools developers use with it.
> > http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

Erik:
I had a glance at the diff: Seems perfect fine to me.

The only issue I have is related to the type attribute:

Could you please add another attribute that defines if the stop has to be 
counted against the major or minor train reach? Maybe call this revenueType or 
scoreType? Values are {major|minor}. Or rename the type attribute to name and 
call that type. 

Answer to your questions below.

Stefan

PS: On some occasions the methods to ask for stops are still label getCities. 
Maybe you could change that accordingly?


On Friday, August 12, 2011 02:47:02 pm Erik Vos wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
> 
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
Sure, see above.
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)

Push after merge.

> Q3. See point 6: some algorithms classes currently pick up values from
> HexMap.  The current code requires that these values should be taken from
> Stop (see comments below).  Would that be OK for you?  Or should I add
> methods to HexMap and/or Tile that honour defaults?

Asking the stop only was exactly the solution I prefer. I will adapt the 
algorithm code myself after you have pushed it.

> 
> Here is the overview (I'll put it into the wiki later):
> 
> 1. City has been renamed to Stop. This object represents a train stop on a
> certain tile that has been laid on a certain hex.
> Stop will become the primary source of all properties that are required to
> define routes and calculate revenues.
> (I have left Station as it is, because this object name equates to the
> corresponding tag names in Tile.xml,
> which I did not want to change after all.  I hope we can live with this
> slight naming inconsistency.)
> 
> 2. The Stop properties can be derived from either MapHex (defined in
> Map.xml) or Tile (defined in TileSet.xml).
> If both exist, MapHex takes precedence, as it is more specific.
> If neither is defined, it will use defaults on the Manager level in the
> same XML files, with the same precedence.
> See item 5 for details and a precedence list.
> 
> 3. The stop properties are:
> 
> - type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
> I have added offmap because usually different defaults apply.
> However, for train running purposes offmap stops should normally be treated
> as major cities.
> Cities on "red" tiles are marked offmap by default.
> "null" applies to plain track tiles, and allows to define a non-default
> "loop" value (1860), see below.
> 
> - runTo = {no|yes|tokenOnly}. Default "yes".
> "no" would apply to e.g. Birmingham in 1851 before phase 4 and
> Elsaß-Lothringen in 1835 except in phase 2.
> "tokenOnly" would apply to e.g. the 18Scan red cities.
> This usage implies that the runTo value may be phase-dependent.
> 
> - runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
> "yes" obviously only applies if the city is not closed (i.e. filled by
> tokens of other companies).
> "no" would apply to standard off-map areas,
> "tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
> Is there a need for "always" (i.e., even if closed)? Any other special
> cases?
> 
> 4. A somewhat related new MapHex property (also accessible to Stop, but not
> restricted to tiles with stops) is:
> - loop = {yes|no}, which defines if one train may touch a hex more than
> once.  Default "yes" (exception: offmap "no").
> "no" applies to *all* tiles in 1860.
> 
> 5. Defaults per stop type, and generic defaults (type=null) can be defined
> in Map.xml and TileSet.xml.
> These defaults are parsed and stored in MapManager and TileManager,
> respectively.
> The precedence is (the first non-null value found is used):
> - specific Hex
> - specific Tile
> - Hex default per stop type
> - Tile default per stop type
> - generic Hex default (type=null)
> - generic Tile default (type = null)
> - final default as defined above.
> 
> I believe this all gives enough flexibility, but of course the proof of the
> pudding is in the eating.
> I have tested settings at various but not all levels.  Current usage
> effectively only needs the first and last level.
> 
> 6. Stop, Tile and MapHex all have these four methods:
> Stop.Type getType() or getStopType(),
> Stop.RunTo isRunToAllowed(),
> Stop.RunThrough isRunThroughAllowed(),
> Stop.Loop isLoopAllowed().
> However, only the return values from Stop follow the precedence rules. The
> values from HexMap and Tile only return any *explicit* settings in <Hex>
> and <Tile>, so these are of little use.
> Please let me know if that could be a problem for some use cases.  I would
> have to add separate methods if these return values should also honour the
> defaults.
> 
> (Note: the existing HexMap.Run type has been split and moved to Stop.  The
> algorithms classes still pick up values from HexMap, which is no longer
> correct, see above.)
> 
> I have so far added explicit settings to the following cases (all in
> Map.xml):
> 1830: The PRR [and Reading] bases: runThrough="tokenOnly".
> 1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
> tile -939 already behaves correctly, but that one has been manually
> tweaked).
> 18EU Paris/Berlin/Vienna: loop="no".
> 
> The Stop code temporarily logs all Stop settings in a way that stands out,
> so that checking the effects of any trial settings should be easy.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

OK, here is a diff.
(I did this from the command line, as I could not find how to do it in Egit.  It's a git diff).

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Friday, August 12, 2011 5:30 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> On Fri, Aug 12, 2011 at 5:47 AM, Erik Vos <eri...@xs...> wrote:
> > I have implemented (but not yet pushed) the train stop properties that
> > we have discussed a while ago, all described below.
> >
> > My questions are (in particular so Stefan):
> > Q1. Do you like it this way?  Is it usable?
> > Q2. What shall I do to the repository?  Push the branch? Or push it
> > merged with master?  Or first redo it all because you don't like it?
> > ;-)
> 
> 
> You can also diff your branch against master, and post the diff to the mailing
> list.  ;-)
> 
> ---Brett.
> 
> ------------------------------------------------------------------------------
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy to use, easy to
> manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

On Fri, Aug 12, 2011 at 5:47 AM, Erik Vos <eri...@xs...> wrote:
> I have implemented (but not yet pushed) the train stop properties that we
> have discussed a while ago, all described below.
>
> My questions are (in particular so Stefan):
> Q1. Do you like it this way?  Is it usable?
> Q2. What shall I do to the repository?  Push the branch? Or push it merged
> with master?  Or first redo it all because you don't like it? ;-)


You can also diff your branch against master, and post the diff to the
mailing list.  ;-)

---Brett.

Re: [Rails-devel] Current implementation, branch Rails 2.0?

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

Hi Stefan,

I agree with 100% of what you are saying, but there is one implicit
presumption: that we can avoid side effects.  And that isn't generally true.

Take your alternative proposal to handle phase actions (or triggers - I
don't like that word either, but that aside).  
Now the Phase tries to reach the action taker by calling a stub, that call
is passed on and must in some Round subclass be implemented with actual
code.
You propose a register-and-call-back approach, which is fine, if only the
action taker can access the registration point. Getting access is the
central problem; read on.

There is quite some history before I arrived at the current architecture. 
Originally I tried to follow the let-each-object-mind-its-own-business
approach (following the original OO paradigm), which led to a situation
where many different objects (portfolios, public companies etc.) were
executing various parts of particular action types.
This worked in simple cases, but as more features got implemented, more
side-effects cropped up, where code in various objects needed to call
methods in different, sometimes remote objects.  So the question arose how
an object can get access to another object to which it doesn't have a direct
reference.

Initially this was often done via static methods calls.  But I had to
abandon that approach as I realised that it would inhibit foreseen future
developments.

Mainly in the last two years I found myself following two paths:
1. Move code out of the objects into the Round classes, which have easier
access to other objects via the GameManager.  You will not believe it, but
in my perception these moves have much simplified and clarified the affected
code parts.
2. Pass down references to the various managers (including GameManager),
usually via the ubiquitous finishConfiguration methods, which are
specifically intended to create any required relationships after all XML has
been parsed.

There transitions aren't complete, but now that we have most OR code in the
OR class, it has become much easier to add new or override existing
behaviour.  And about every object is now reachable from there.

The situation has become much more complex with the advent of
rounds-within-rounds in 1856, 1835 and 18EU.  In 1835, Prussian formation
rounds even run inside company turns.  It took a while before I had arrived
at a workable approach to make this happen.

Now I'm facing your proposal to fragment the OR class into an untold number
of separate classes.  Your example of the correction classes is instructive,
and I regret that I have not looked at and learned from your code in an
earlier stage. But correction is a very simple case, out of the game as it
were, with just one item being affected without side effects.  Fine.  But
I'm far from convinced that it will look equally nice if we are going to
apply this concept to real game actions, with all required side effects, and
that it really will simplify rather than even more complicate the code.

You certainly have set my thoughts in motion, and I'm open to be convinced
by more realistic examples.  But I hope you'll understand that I have no
great desire to set myself to start reworking these central concepts once
again.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, August 11, 2011 10:38 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Current implementation, branch Rails 2.0?
> 
> > All fine, but so what?  Is size bad per se?
> >
> 
> Erik,
> No certainly not. All this is not about good or bad. In one sense the size
> shows the thoughts and efforts for all details you have put into those
classes.
> 
> It is the other way around: As I do not have the time and the memory to
> understand all thoughts and conditions you considered, that created that
> code, I would prefer to digest all that in little portions.
> 
> Organizing code into classes allows to review only the relevant classes
that
> you need know. It is like organizing stuff into little boxes where you put
> labels on the boxes what is inside. This makes it much easier to find
things
> and to understand the big picture: Maybe like in a big department store:
It is
> much easier to get an overview by studying the directory of the store
instead
> of searching every shelf.
> 
> An object orientated languages allows storing pieces of code in classes
and if
> I want rewrite/change/add something to a class, I have to make sure that
> after my changes everything works as before. If the class is small, it is
easier
> to check if I do not introduce side effects and I only have to test the
part
> where the class is responsible for: So take the example for the
> OperatingRound. If I change anything inside I have to test all
functionality
> which is managed by the OperatingRound. Thus I change something related
> to token lay, it can potentially have side effects on tile laying, revenue
> payouts, train buying, loans etc.
> 
> If the token lay code is inside in a separate class it is impossible to
effect the
> other functionality of OperatingRound.
> 
> I had the issue more than a year ago: I started adding the NoMap
> functionalities which in principle should only change Tile and Token Lay.
> However due to side effects of my (at that time bad understanding) of the
> step mechanism inside the OperatingRound I broke the 1856 loan
> mechanism.
> And I was not even aware of that code as this code was part of a subclass
of
> OperatingRound.
> 
> The same issue about the size of classes effects writing unit tests: For
> refactoring the best is to have the class covered fully by unit tests. If
you
> have two small classes instead of one large you can start refactoring
earlier
> than you had to write all tests first.
> 
> And the other good thing is, that with smaller classes it is less likely
that two
> people work at the same time on the same class, thus it makes merging and
> potential merge conflicts less likely.
> 
> For my daily job I have to deal with large programs in non-object
orientated
> languages and even there I prefer to split problems into smaller,
> independent pieces. Especially if you come back to those programs several
> years later, it makes it much easier to enhance or fix something.
> 
> OK enough text, but it is not about fashionable or good/bad, it is simply
> about making coding easier and so increase the fun part of it.
> 
> Stefan
> 
> ´
> 
>
----------------------------------------------------------------------------
--
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out
of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] GameManager and players array problem (Java implementation of reordering players)

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

Hi Martin,

 

It is one thing that the UI player order does not change; that is a
presentation question.

But it is another thing if cash or share movements affect the wrong players,
at least as it is shown in the UI. That would be a bug.

 

It is well possible that the effects of the changed player order have not
yet been fully worked out, but to look into that I need an example.

Do you have a saved file that I can run against the current code and that
shows the bug?  

If I need any of your new code to show this bug, you could send me a patch.
In the new Git environment I can easily create a local branch that does not
affect the central repository.

 

(I have one 1880 saved file from you, but it doesn't load because it appears
to require a class rails.game.specific._1880.StockMarket_1880 that I don't
have.)

 

Erik. 

 

From: Dr. Martin Brumm [mailto:dr....@t-...] 
Sent: Friday, August 12, 2011 7:30 AM
To: Rails Developer Liste
Subject: [Rails-devel] GameManager and players array problem (Java
implementation of reordering players)

 

Hi Brett, Erik and Stefan et al. 

 

For the background information, 

 

1880 and a number of other games change the seat order after the starting or
in the starting round based on certain auction results.

 

Eric helped me to bring in a reorder routine in rails.game.gamemanager
called reorderPlayerByCash which should reorder the players array based on
their wallet.

 

This seems to function well inside the scope of the Roundclass and its
subclasses. 

 

But to my astonishment or Javanewbeeness the changed array players doesn't
show in the gameManager itself if you watch the array in debug mode outside
of the Roundclasses (i.e. rails.ui.swing.startwindow and Statuswindow). So
naturally the changed playerorder cant be accessed from that classes and
thus the changed seating order doesn't reflect it self in the ui. Whereas
the actions taken in the rounds are nevertheless credited right in the ui
display. This leads in a Stockround to the funny actions that Player A is
shown as active and upon acting his action leads to result for player C for
example.

 

So if anyone of you could point me at the silly simple (I assume) mistake in
my train of thought in implementing  the reordering I would be very
grateful.

 

Regards,

Martin

[Rails-devel] Stop properties

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

I have implemented (but not yet pushed) the train stop properties that we
have discussed a while ago, all described below. 

My questions are (in particular so Stefan):
Q1. Do you like it this way?  Is it usable?
Q2. What shall I do to the repository?  Push the branch? Or push it merged
with master?  Or first redo it all because you don't like it? ;-)
Q3. See point 6: some algorithms classes currently pick up values from
HexMap.  The current code requires that these values should be taken from
Stop (see comments below).  Would that be OK for you?  Or should I add
methods to HexMap and/or Tile that honour defaults?

Here is the overview (I'll put it into the wiki later):

1. City has been renamed to Stop. This object represents a train stop on a
certain tile that has been laid on a certain hex. 
Stop will become the primary source of all properties that are required to
define routes and calculate revenues.
(I have left Station as it is, because this object name equates to the
corresponding tag names in Tile.xml, 
which I did not want to change after all.  I hope we can live with this
slight naming inconsistency.)

2. The Stop properties can be derived from either MapHex (defined in
Map.xml) or Tile (defined in TileSet.xml).  
If both exist, MapHex takes precedence, as it is more specific.
If neither is defined, it will use defaults on the Manager level in the same
XML files, with the same precedence. 
See item 5 for details and a precedence list.

3. The stop properties are:

- type = {major|minor|offmap|medium|halt|pass|port|mine|null} .
I have added offmap because usually different defaults apply. 
However, for train running purposes offmap stops should normally be treated
as major cities.
Cities on "red" tiles are marked offmap by default.
"null" applies to plain track tiles, and allows to define a non-default
"loop" value (1860), see below.

- runTo = {no|yes|tokenOnly}. Default "yes".
"no" would apply to e.g. Birmingham in 1851 before phase 4 and
Elsaß-Lothringen in 1835 except in phase 2. 
"tokenOnly" would apply to e.g. the 18Scan red cities.
This usage implies that the runTo value may be phase-dependent.

- runThrough = {no|yes|tokenOnly}.  Default "yes" (exception: offmap "no").
"yes" obviously only applies if the city is not closed (i.e. filled by
tokens of other companies).
"no" would apply to standard off-map areas, 
"tokenOnly" would apply to 1830 Altoona (PRR base, implying a PRR token).
Is there a need for "always" (i.e., even if closed)? Any other special
cases?

4. A somewhat related new MapHex property (also accessible to Stop, but not
restricted to tiles with stops) is:
- loop = {yes|no}, which defines if one train may touch a hex more than
once.  Default "yes" (exception: offmap "no").
"no" applies to *all* tiles in 1860.

5. Defaults per stop type, and generic defaults (type=null) can be defined
in Map.xml and TileSet.xml. 
These defaults are parsed and stored in MapManager and TileManager,
respectively.
The precedence is (the first non-null value found is used):
- specific Hex
- specific Tile
- Hex default per stop type
- Tile default per stop type
- generic Hex default (type=null)
- generic Tile default (type = null)
- final default as defined above.

I believe this all gives enough flexibility, but of course the proof of the
pudding is in the eating.
I have tested settings at various but not all levels.  Current usage
effectively only needs the first and last level.

6. Stop, Tile and MapHex all have these four methods:
Stop.Type getType() or getStopType(),
Stop.RunTo isRunToAllowed(), 
Stop.RunThrough isRunThroughAllowed(),
Stop.Loop isLoopAllowed().
However, only the return values from Stop follow the precedence rules. The
values from HexMap and Tile only return any *explicit* settings in <Hex> and
<Tile>, so these are of little use.
Please let me know if that could be a problem for some use cases.  I would
have to add separate methods if these return values should also honour the
defaults.

(Note: the existing HexMap.Run type has been split and moved to Stop.  The
algorithms classes still pick up values from HexMap, which is no longer
correct, see above.)

I have so far added explicit settings to the following cases (all in
Map.xml):
1830: The PRR [and Reading] bases: runThrough="tokenOnly".
1856 Goderich/18EU Hamburg: runThrough="yes" (not really needed, because
tile -939 already behaves correctly, but that one has been manually
tweaked).
18EU Paris/Berlin/Vienna: loop="no".

The Stop code temporarily logs all Stop settings in a way that stands out,
so that checking the effects of any trial settings should be easy.

Erik.

Re: [Rails-devel] 1830 Coalfield bug

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

This is a bug in the current production version of rails, It's already
fixed in the development branch, the next release (unsure when that is
planned for) will fix this.

Phil



On 12 August 2011 08:30,  <ar...@gl...> wrote:
> Recently I started an 1830 Coalfield PBeM. When I made an analysis of what
> to do I found that N&W can not operate. It start token is not placed and
> thus game halts whein it is N&W's turn to operate. See attached save file.
>
> Best
> Arne Östlund
>
> On Thu, 11 Aug 2011 16:18:14 +0000,
> rai...@li... wrote:
>>
>> Send Rails-devel mailing list submissions to
>>        rai...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        https://lists.sourceforge.net/lists/listinfo/rails-devel
>> or, via email, send a message with subject or body 'help' to
>>        rai...@li...
>>
>> You can reach the person managing the list at
>>        rai...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Rails-devel digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: How to clean up the Git index? (Erik Vos)
>>   2. Re: How to clean up the Git index? (brett lentz)
>>   3. Re: How to clean up the Git index? (Erik Vos)
>>   4. 18TN revenue calculation (4ba69a) (Stefan Frey)
>>   5. Automated test reports without currency identifier        (19de64)
>>      (Stefan Frey)
>>   6. Re: Automated test reports without currency       identifier
>>      (19de64) (Erik Vos)
>>   7. Re: Route calculation: Train length heuristic (Stefan Frey)
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 10 Aug 2011 19:22:42 +0200
>> From: "Erik Vos" <eri...@xs...>
>> Subject: Re: [Rails-devel] How to clean up the Git index?
>> To: "'Development list for Rails: an 18xx game'"
>>        <rai...@li...>
>> Message-ID: <002701cc5782$1cb6f8a0$5624e9e0$@xs4all.nl>
>> Content-Type: text/plain;       charset="us-ascii"
>>
>>> Try doing a "git diff" and see what lines it thinks are changed.
>>
>> None.  That's why I'm baffled.
>>
>> Erik.
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 10 Aug 2011 10:34:14 -0700
>> From: brett lentz <bre...@gm...>
>> Subject: Re: [Rails-devel] How to clean up the Git index?
>> To: "Development list for Rails: an 18xx game"
>>        <rai...@li...>
>> Message-ID:
>>
>>  <CAM...@ma...>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> wrote:
>>>>
>>>> Try doing a "git diff" and see what lines it thinks are changed.
>>>
>>> None. ?That's why I'm baffled.
>>>
>>> Erik.
>>
>>
>> Strange.
>>
>> You can always do a "git reset --hard origin/master", but this will
>> destroy any local commits you haven't pushed.
>>
>> A less destructive method is a simple "git reset --hard", which will
>> reset any changes back to the state of your local HEAD.
>>
>> ---Brett.
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 10 Aug 2011 20:36:44 +0200
>> From: "Erik Vos" <eri...@xs...>
>> Subject: Re: [Rails-devel] How to clean up the Git index?
>> To: "'Development list for Rails: an 18xx game'"
>>        <rai...@li...>
>> Message-ID: <002801cc578c$77845160$668cf420$@xs4all.nl>
>> Content-Type: text/plain;       charset="UTF-8"
>>
>> A hard reset did it.  Thanks.
>> Fortunately I had nothing to commit or push, I just wanted a clean
>> house.  Now I have.
>>
>> Erik.
>>
>>> -----Original Message-----
>>> From: brett lentz [mailto:bre...@gm...]
>>> Sent: Wednesday, August 10, 2011 7:34 PM
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] How to clean up the Git index?
>>>
>>> On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> wrote:
>>> >> Try doing a "git diff" and see what lines it thinks are changed.
>>> >
>>> > None.  That's why I'm baffled.
>>> >
>>> > Erik.
>>>
>>>
>>> Strange.
>>>
>>> You can always do a "git reset --hard origin/master", but this will
>>> destroy any
>>> local commits you haven't pushed.
>>>
>>> A less destructive method is a simple "git reset --hard", which will
>>> reset any
>>> changes back to the state of your local HEAD.
>>>
>>> ---Brett.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> uberSVN's rich system and user administration capabilities and model
>>> configuration take the hassle out of deploying and managing Subversion
>>> and
>>> the tools developers use with it. Learn more about uberSVN and get a free
>>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 11 Aug 2011 18:02:34 +0200
>> From: Stefan Frey <ste...@we...>
>> Subject: [Rails-devel] 18TN revenue calculation (4ba69a)
>> To: "Development list for Rails: an 18xx game"
>>        <rai...@li...>
>> Message-ID: <201...@we...>
>> Content-Type: Text/Plain;  charset="us-ascii"
>>
>> I have added the civil war revenue modifier (removing the shortest
>> train of a
>> company at that time), so 18TN should be finished, except for checking if
>> a
>> company has no route at the time of civil war. For that case the revenue
>> has
>> to be adjusted manually.
>>
>> To make this more transparent I allow static revenue modifiers now to add
>> a
>> comment to the detailed revenue message and did this in a few other cases
>> (e.g. if a bonus was active for a company etc.)
>>
>> Stefan
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 11 Aug 2011 18:11:45 +0200
>> From: Stefan Frey <ste...@we...>
>> Subject: [Rails-devel] Automated test reports without currency
>>        identifier      (19de64)
>> To: "Development list for Rails: an 18xx game"
>>        <rai...@li...>
>> Message-ID: <201...@we...>
>> Content-Type: Text/Plain;  charset="iso-8859-15"
>>
>> I agree that it is the better solution to have UTF-8 working all the time
>> (maybe Brett could check the setup of the git repo?)
>> However it was easy to adjust the test.profile such that the reports do
>> not
>> contain the problematic yen and euro currency characters.
>>
>>
>> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
>>>
>>> On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:
>>> > The encoding (at least accoding to my editor) of the report files is
>>> > still UTF-8 and they open up in the editor correctly.
>>> > All tests report passed as well.
>>> > However to avoid those issues I suggest to remove the currency
>>> > indicator
>>> > from
>>> > the report files used for testing.
>>> > I can do the code change tomorrow.
>>>
>>> It won't be just currency characters -- you would have to avoid all names
>>> in the game as well.
>>>
>>> Better to make sure everything is always stored as UTF8 and interpreted
>>> as
>>> UTF8 and be done with it.
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 11 Aug 2011 18:14:25 +0200
>> From: "Erik Vos" <eri...@xs...>
>> Subject: Re: [Rails-devel] Automated test reports without currency
>>        identifier      (19de64)
>> To: "'Development list for Rails: an 18xx game'"
>>        <rai...@li...>
>> Message-ID: <002001cc5841$bd7ff560$387fe020$@xs4all.nl>
>> Content-Type: text/plain;       charset="iso-8859-1"
>>
>> But that doesn't fix the same problem with KK?B in 18EU.
>>
>> Erik.
>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Thursday, August 11, 2011 6:12 PM
>>> To: Development list for Rails: an 18xx game
>>> Subject: [Rails-devel] Automated test reports without currency identifier
>>> (19de64)
>>>
>>> I agree that it is the better solution to have UTF-8 working all the time
>>> (maybe Brett could check the setup of the git repo?) However it was easy
>>
>> to
>>>
>>> adjust the test.profile such that the reports do not contain the
>>
>> problematic
>>>
>>> yen and euro currency characters.
>>>
>>>
>>> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
>>> > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
>>> wrote:
>>> > > The encoding (at least accoding to my editor) of the report files is
>>> > > still UTF-8 and they open up in the editor correctly.
>>> > > All tests report passed as well.
>>> > > However to avoid those issues I suggest to remove the currency
>>> > > indicator from the report files used for testing.
>>> > > I can do the code change tomorrow.
>>> >
>>> > It won't be just currency characters -- you would have to avoid all
>>> > names in the game as well.
>>> >
>>> > Better to make sure everything is always stored as UTF8 and
>>> > interpreted as
>>> > UTF8 and be done with it.
>>>
>>>
>>
>>
>> ----------------------------------------------------------------------------
>> --
>>>
>>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
>>> administration capabilities and model configuration. Take the hassle out
>>
>> of
>>>
>>> deploying and managing Subversion and the tools developers use with it.
>>> http://p.sf.net/sfu/wandisco-dev2dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 11 Aug 2011 18:20:44 +0200
>> From: Stefan Frey <ste...@we...>
>> Subject: Re: [Rails-devel] Route calculation: Train length heuristic
>> To: "Development list for Rails: an 18xx game"
>>        <rai...@li...>
>> Message-ID: <201...@we...>
>> Content-Type: Text/Plain;  charset="iso-8859-1"
>>
>> Erik,
>> it is already implemented (in a local branch, otherwise I would have
>> not been
>> able to report running times).
>>
>> However I want to run some more tests before pushing it.
>>
>> The answer to your question is no:I it does not require a train config
>> attribute as the train domination is implemented as a Comparator (method)
>> in
>> the NetworkTrain class.
>>
>> So the train conditions could be checked automatically, however there can
>> be
>> certain conditions in specific games that break the heuristic, for example
>> bonuses that are only valid for specific trains (e.g. if in 18AL players
>> decide to have the director assign the named train themselves).
>>
>> As the heuristic is only necessary in games with very long trains (as
>> in 1830,
>> 1856, 1870) I want to be on the safe side and only activate the heuristic
>> in
>> those games after some tests by providing a global switch as an attribute
>> to
>> the RevenueManager in game.xml.
>>
>> Stefan
>>
>>
>> On Tuesday, August 09, 2011 11:14:47 am Erik Vos wrote:
>>>
>>> Stefan,
>>>
>>> Do you plan to implement this heuristic in Rails?
>>> Would it require a new TrainType config attribute, like <TrainType
>>> name="6+6" ... dominates="6,5+5"/>?
>>>
>>> Erik.
>>>
>>> > -----Original Message-----
>>> > From: Stefan Frey [mailto:ste...@we...]
>>> > Sent: Tuesday, August 09, 2011 7:03 AM
>>> > To: Development list for Rails: an 18xx game
>>> > Subject: [Rails-devel] Route calculation: Train length heuristic
>>> >
>>> > A year ago I suggested another heuristic to improve the speed of the
>>> > revenue calculation.
>>> >
>>> > The idea is to use what 1830 players automatically do:
>>> > If you calculate a run for a 4 and a 3 train, you already know that you
>>>
>>> will end
>>>
>>> > up with a longer route (more stations) for the 4 train and a shorter
>>> > route
>>>
>>> for
>>>
>>> > the 3 train. Similar for running a Diesel and a 5 train.
>>> >
>>> > However this knowledge is not taken into account by the current
>>> > algorithm. Things unfortunately are not that easy for all 18xx as it
>>> > are
>>> > in 1830. For example in 1835 one cannot tell this ex-ante for a
>>> > combination of a
>>>
>>> 5+5
>>>
>>> > and a 6 train. That in fact is one the reasons why calculating the
>>>
>>> Preussian
>>>
>>> > routes is not an easy task.
>>> >
>>> > Another exceptions are: If trains score differently for the same route
>>> > (Express (xE) and Double (xD) trains) or if hex trains run jointly with
>>>
>>> standard
>>>
>>> > trains.
>>> >
>>> > ** The formal definition of train domination:
>>> >
>>> > If the "better" train A can run all routes that the "weaker" train B
>>> > and
>>>
>>> train A
>>>
>>> > scores identical revenue on all routes as B, then I define that train A
>>> > dominates train B.
>>> >
>>> > If A dominates B I write this as A>B, otherwise the trains are either
>>>
>>> identical
>>>
>>> > (A=B) or neither dominates (A<>B).
>>> >
>>> > If train A dominates train B, the length of the route of train A will
>>>
>>> always be
>>>
>>> > longer or at least equally long as that of train B.
>>> > (Length of the route is the number of stations scored.)
>>> >
>>> > ** Examples should make this clearer.
>>> >
>>> > In 1830 it is easy:  D>6>5>4>3>2
>>> >
>>> > In 1835 it is
>>> > 6+6 > 5+5 > 4+4 > 3+3 > 2+2
>>> > 6 > 5 > 4 > 3 > 2
>>> > 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
>>> > 6 > 3+3, 4 > 2+2
>>> > But for example: 6 <> 5+5, 5 <> 3+3 etc.
>>> >
>>> > ** Implementation
>>> > The implementation is pretty straight forward and only requires a few
>>>
>>> lines
>>>
>>> > of code in the revenue calculator. The major change is to order the
>>> > trains
>>>
>>> by
>>>
>>> > the criteria "train domination". Then the calculator assigns the
>>> > initial
>>>
>>> train
>>>
>>> > length for the dominated train not with the maximum length of that
>>> > train,
>>> > but with the (current) route length of the dominating train. This
>>> > ensures
>>>
>>> that
>>>
>>> > the dominating train will always have the longer route assigned.
>>> >
>>> > ** Speed improvement
>>> > I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR
>>>
>>> scenarios and
>>>
>>> > came to the following running times (more statistics on number of
>>> > routes
>>> > evaluated and when the best solution was found see below).
>>> >
>>> > For the simpler network (A) running times decrease from around 5
>>> > minutes
>>> > to
>>> > 3.5 minutes (my CPU is more powerful than Alizas ...).
>>> > For the extensive network (B) running times decrease from around 1 hour
>>> > to around 30 minutes.
>>> >
>>> > Overall the improvement it seems that the speed is improved by around
>>> > 50%
>>> > to 200%, so time to wait is down by 33% to 66%, which is not bad.
>>> >
>>> > But as it can be clearly seen by comparison with a double Diesel
>>> > scenarios
>>>
>>> the
>>>
>>> > exponential characteristic of the algorithm is still very clear.
>>> >
>>> > So I still hope that John Tamplin can give some hints on his lost flow
>>>
>>> algorithm
>>>
>>> > for those who want to run triple Diesel more often.
>>> >
>>> > Stefan
>>> >
>>> > ** Stats
>>> >
>>> > => Aliza Scenario 1856 A:
>>> > 31 vertices with 41 edges
>>> > 10 startvertices
>>> >
>>> > Values:
>>> > Single D: 700
>>> > Double D: 920
>>> > Triple D: 1120
>>> >
>>> > Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
>>> >
>>> > Without dominant trains:
>>> > Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions Triple D: 290
>>> > seconds / 114.9M Evaluations, 129.5M Predictions
>>> > (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
>>> >
>>> > With dominant trains:
>>> > Double D: 1 second / 323k Evaluations, 385k Predictions Triple D: 206
>>>
>>> seconds
>>>
>>> > / 87.4M Evaluations, 98.0M Predictions
>>> > (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
>>> >
>>> > => Aliza Scenario 1856 B:
>>> > 34 vertices with 50 edges
>>> > 10 startvertices
>>> >
>>> > Values:
>>> > Single D: 790
>>> > Double D: 1280
>>> > Triple D: 1440
>>> >
>>> > Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
>>> >
>>> > Without dominant trains:
>>> > Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions Triple D:
>>> > 3551
>>> > seconds / 1473M Evaluations, 1709M Predictions
>>> > (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
>>> >
>>> > With dominant trains:
>>> > Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions Triple D: 1926
>>> > seconds / 832M Evaluations, 962M Predictions
>>> > (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
>>> >
>>> > => Scenario 1870:
>>> > This is the route network used for testing a year ago,
>>> >
>>> > 23 vertices with 57 edges
>>> > 1 startvertex
>>> >
>>> > Values:
>>> > Single 12: 380
>>> > Double 12: 690
>>> > Triple 12: 820
>>> >
>>> > Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
>>> >
>>> > Without dominant trains:
>>> > Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions Triple 12:
>>> > 104
>>> > seconds / 23.4M Evaluations, 61.6M Predictions
>>> > (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
>>> >
>>> > With dominant trains:
>>> > Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions Triple 12: 49
>>> > seconds / 8.1M Evaluations, 30.0M Predictions
>>> > (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
>>>
>>>
>>>
>>> ---------------------------------------------------------------------------
>>> - --
>>>
>>> > uberSVN's rich system and user administration capabilities and model
>>> > configuration take the hassle out of deploying and managing Subversion
>>> > and the tools developers use with it. Learn more about uberSVN and get
>>> > a
>>> > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>> > _______________________________________________
>>> > Rails-devel mailing list
>>> > Rai...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>>
>>> ---------------------------------------------------------------------------
>>> --- uberSVN's rich system and user administration capabilities and model
>>> configuration take the hassle out of deploying and managing Subversion
>>> and
>>> the tools developers use with it. Learn more about uberSVN and get a free
>>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>> ------------------------------
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it.
>> http://p.sf.net/sfu/wandisco-dev2dev
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> End of Rails-devel Digest, Vol 45, Issue 12
>> *******************************************
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 1830 Coalfield bug

[<ar...@gl...>]

 Recently I started an 1830 Coalfield PBeM. When I made an analysis of 
 what to do I found that N&W can not operate. It start token is not 
 placed and thus game halts whein it is N&W's turn to operate. See 
 attached save file.

 Best
 Arne Östlund

 On Thu, 11 Aug 2011 16:18:14 +0000, 
 rai...@li... wrote:
> Send Rails-devel mailing list submissions to
> 	rai...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/rails-devel
> or, via email, send a message with subject or body 'help' to
> 	rai...@li...
>
> You can reach the person managing the list at
> 	rai...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rails-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: How to clean up the Git index? (Erik Vos)
>    2. Re: How to clean up the Git index? (brett lentz)
>    3. Re: How to clean up the Git index? (Erik Vos)
>    4. 18TN revenue calculation (4ba69a) (Stefan Frey)
>    5. Automated test reports without currency identifier	(19de64)
>       (Stefan Frey)
>    6. Re: Automated test reports without currency	identifier
>       (19de64) (Erik Vos)
>    7. Re: Route calculation: Train length heuristic (Stefan Frey)
>
>
> 
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Aug 2011 19:22:42 +0200
> From: "Erik Vos" <eri...@xs...>
> Subject: Re: [Rails-devel] How to clean up the Git index?
> To: "'Development list for Rails: an 18xx game'"
> 	<rai...@li...>
> Message-ID: <002701cc5782$1cb6f8a0$5624e9e0$@xs4all.nl>
> Content-Type: text/plain;	charset="us-ascii"
>
>> Try doing a "git diff" and see what lines it thinks are changed.
>
> None.  That's why I'm baffled.
>
> Erik.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Aug 2011 10:34:14 -0700
> From: brett lentz <bre...@gm...>
> Subject: Re: [Rails-devel] How to clean up the Git index?
> To: "Development list for Rails: an 18xx game"
> 	<rai...@li...>
> Message-ID:
> 	<CAM...@ma...>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> 
> wrote:
>>> Try doing a "git diff" and see what lines it thinks are changed.
>>
>> None. ?That's why I'm baffled.
>>
>> Erik.
>
>
> Strange.
>
> You can always do a "git reset --hard origin/master", but this will
> destroy any local commits you haven't pushed.
>
> A less destructive method is a simple "git reset --hard", which will
> reset any changes back to the state of your local HEAD.
>
> ---Brett.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Aug 2011 20:36:44 +0200
> From: "Erik Vos" <eri...@xs...>
> Subject: Re: [Rails-devel] How to clean up the Git index?
> To: "'Development list for Rails: an 18xx game'"
> 	<rai...@li...>
> Message-ID: <002801cc578c$77845160$668cf420$@xs4all.nl>
> Content-Type: text/plain;	charset="UTF-8"
>
> A hard reset did it.  Thanks.
> Fortunately I had nothing to commit or push, I just wanted a clean
> house.  Now I have.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Wednesday, August 10, 2011 7:34 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] How to clean up the Git index?
>>
>> On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> 
>> wrote:
>> >> Try doing a "git diff" and see what lines it thinks are changed.
>> >
>> > None.  That's why I'm baffled.
>> >
>> > Erik.
>>
>>
>> Strange.
>>
>> You can always do a "git reset --hard origin/master", but this will 
>> destroy any
>> local commits you haven't pushed.
>>
>> A less destructive method is a simple "git reset --hard", which will 
>> reset any
>> changes back to the state of your local HEAD.
>>
>> ---Brett.
>>
>> 
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing 
>> Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a 
>> free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 11 Aug 2011 18:02:34 +0200
> From: Stefan Frey <ste...@we...>
> Subject: [Rails-devel] 18TN revenue calculation (4ba69a)
> To: "Development list for Rails: an 18xx game"
> 	<rai...@li...>
> Message-ID: <201...@we...>
> Content-Type: Text/Plain;  charset="us-ascii"
>
> I have added the civil war revenue modifier (removing the shortest
> train of a
> company at that time), so 18TN should be finished, except for 
> checking if a
> company has no route at the time of civil war. For that case the 
> revenue has
> to be adjusted manually.
>
> To make this more transparent I allow static revenue modifiers now to 
> add a
> comment to the detailed revenue message and did this in a few other 
> cases
> (e.g. if a bonus was active for a company etc.)
>
> Stefan
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 11 Aug 2011 18:11:45 +0200
> From: Stefan Frey <ste...@we...>
> Subject: [Rails-devel] Automated test reports without currency
> 	identifier	(19de64)
> To: "Development list for Rails: an 18xx game"
> 	<rai...@li...>
> Message-ID: <201...@we...>
> Content-Type: Text/Plain;  charset="iso-8859-15"
>
> I agree that it is the better solution to have UTF-8 working all the 
> time
> (maybe Brett could check the setup of the git repo?)
> However it was easy to adjust the test.profile such that the reports 
> do not
> contain the problematic yen and euro currency characters.
>
>
> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
>> On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> 
>> wrote:
>> > The encoding (at least accoding to my editor) of the report files 
>> is
>> > still UTF-8 and they open up in the editor correctly.
>> > All tests report passed as well.
>> > However to avoid those issues I suggest to remove the currency 
>> indicator
>> > from
>> > the report files used for testing.
>> > I can do the code change tomorrow.
>>
>> It won't be just currency characters -- you would have to avoid all 
>> names
>> in the game as well.
>>
>> Better to make sure everything is always stored as UTF8 and 
>> interpreted as
>> UTF8 and be done with it.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 11 Aug 2011 18:14:25 +0200
> From: "Erik Vos" <eri...@xs...>
> Subject: Re: [Rails-devel] Automated test reports without currency
> 	identifier	(19de64)
> To: "'Development list for Rails: an 18xx game'"
> 	<rai...@li...>
> Message-ID: <002001cc5841$bd7ff560$387fe020$@xs4all.nl>
> Content-Type: text/plain;	charset="iso-8859-1"
>
> But that doesn't fix the same problem with KK?B in 18EU.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Thursday, August 11, 2011 6:12 PM
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] Automated test reports without currency 
>> identifier
>> (19de64)
>>
>> I agree that it is the better solution to have UTF-8 working all the 
>> time
>> (maybe Brett could check the setup of the git repo?) However it was 
>> easy
> to
>> adjust the test.profile such that the reports do not contain the
> problematic
>> yen and euro currency characters.
>>
>>
>> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
>> > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
>> wrote:
>> > > The encoding (at least accoding to my editor) of the report 
>> files is
>> > > still UTF-8 and they open up in the editor correctly.
>> > > All tests report passed as well.
>> > > However to avoid those issues I suggest to remove the currency
>> > > indicator from the report files used for testing.
>> > > I can do the code change tomorrow.
>> >
>> > It won't be just currency characters -- you would have to avoid 
>> all
>> > names in the game as well.
>> >
>> > Better to make sure everything is always stored as UTF8 and
>> > interpreted as
>> > UTF8 and be done with it.
>>
>>
> 
> ----------------------------------------------------------------------------
> --
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
>> administration capabilities and model configuration. Take the hassle 
>> out
> of
>> deploying and managing Subversion and the tools developers use with 
>> it.
>> http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 11 Aug 2011 18:20:44 +0200
> From: Stefan Frey <ste...@we...>
> Subject: Re: [Rails-devel] Route calculation: Train length heuristic
> To: "Development list for Rails: an 18xx game"
> 	<rai...@li...>
> Message-ID: <201...@we...>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> Erik,
> it is already implemented (in a local branch, otherwise I would have
> not been
> able to report running times).
>
> However I want to run some more tests before pushing it.
>
> The answer to your question is no:I it does not require a train 
> config
> attribute as the train domination is implemented as a Comparator 
> (method) in
> the NetworkTrain class.
>
> So the train conditions could be checked automatically, however there 
> can be
> certain conditions in specific games that break the heuristic, for 
> example
> bonuses that are only valid for specific trains (e.g. if in 18AL 
> players
> decide to have the director assign the named train themselves).
>
> As the heuristic is only necessary in games with very long trains (as
> in 1830,
> 1856, 1870) I want to be on the safe side and only activate the 
> heuristic in
> those games after some tests by providing a global switch as an 
> attribute to
> the RevenueManager in game.xml.
>
> Stefan
>
>
> On Tuesday, August 09, 2011 11:14:47 am Erik Vos wrote:
>> Stefan,
>>
>> Do you plan to implement this heuristic in Rails?
>> Would it require a new TrainType config attribute, like <TrainType
>> name="6+6" ... dominates="6,5+5"/>?
>>
>> Erik.
>>
>> > -----Original Message-----
>> > From: Stefan Frey [mailto:ste...@we...]
>> > Sent: Tuesday, August 09, 2011 7:03 AM
>> > To: Development list for Rails: an 18xx game
>> > Subject: [Rails-devel] Route calculation: Train length heuristic
>> >
>> > A year ago I suggested another heuristic to improve the speed of 
>> the
>> > revenue calculation.
>> >
>> > The idea is to use what 1830 players automatically do:
>> > If you calculate a run for a 4 and a 3 train, you already know 
>> that you
>>
>> will end
>>
>> > up with a longer route (more stations) for the 4 train and a 
>> shorter
>> > route
>>
>> for
>>
>> > the 3 train. Similar for running a Diesel and a 5 train.
>> >
>> > However this knowledge is not taken into account by the current
>> > algorithm. Things unfortunately are not that easy for all 18xx as 
>> it are
>> > in 1830. For example in 1835 one cannot tell this ex-ante for a
>> > combination of a
>>
>> 5+5
>>
>> > and a 6 train. That in fact is one the reasons why calculating the
>>
>> Preussian
>>
>> > routes is not an easy task.
>> >
>> > Another exceptions are: If trains score differently for the same 
>> route
>> > (Express (xE) and Double (xD) trains) or if hex trains run jointly 
>> with
>>
>> standard
>>
>> > trains.
>> >
>> > ** The formal definition of train domination:
>> >
>> > If the "better" train A can run all routes that the "weaker" train 
>> B and
>>
>> train A
>>
>> > scores identical revenue on all routes as B, then I define that 
>> train A
>> > dominates train B.
>> >
>> > If A dominates B I write this as A>B, otherwise the trains are 
>> either
>>
>> identical
>>
>> > (A=B) or neither dominates (A<>B).
>> >
>> > If train A dominates train B, the length of the route of train A 
>> will
>>
>> always be
>>
>> > longer or at least equally long as that of train B.
>> > (Length of the route is the number of stations scored.)
>> >
>> > ** Examples should make this clearer.
>> >
>> > In 1830 it is easy:  D>6>5>4>3>2
>> >
>> > In 1835 it is
>> > 6+6 > 5+5 > 4+4 > 3+3 > 2+2
>> > 6 > 5 > 4 > 3 > 2
>> > 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
>> > 6 > 3+3, 4 > 2+2
>> > But for example: 6 <> 5+5, 5 <> 3+3 etc.
>> >
>> > ** Implementation
>> > The implementation is pretty straight forward and only requires a 
>> few
>>
>> lines
>>
>> > of code in the revenue calculator. The major change is to order 
>> the
>> > trains
>>
>> by
>>
>> > the criteria "train domination". Then the calculator assigns the 
>> initial
>>
>> train
>>
>> > length for the dominated train not with the maximum length of that 
>> train,
>> > but with the (current) route length of the dominating train. This 
>> ensures
>>
>> that
>>
>> > the dominating train will always have the longer route assigned.
>> >
>> > ** Speed improvement
>> > I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR
>>
>> scenarios and
>>
>> > came to the following running times (more statistics on number of 
>> routes
>> > evaluated and when the best solution was found see below).
>> >
>> > For the simpler network (A) running times decrease from around 5 
>> minutes
>> > to
>> > 3.5 minutes (my CPU is more powerful than Alizas ...).
>> > For the extensive network (B) running times decrease from around 1 
>> hour
>> > to around 30 minutes.
>> >
>> > Overall the improvement it seems that the speed is improved by 
>> around 50%
>> > to 200%, so time to wait is down by 33% to 66%, which is not bad.
>> >
>> > But as it can be clearly seen by comparison with a double Diesel
>> > scenarios
>>
>> the
>>
>> > exponential characteristic of the algorithm is still very clear.
>> >
>> > So I still hope that John Tamplin can give some hints on his lost 
>> flow
>>
>> algorithm
>>
>> > for those who want to run triple Diesel more often.
>> >
>> > Stefan
>> >
>> > ** Stats
>> >
>> > => Aliza Scenario 1856 A:
>> > 31 vertices with 41 edges
>> > 10 startvertices
>> >
>> > Values:
>> > Single D: 700
>> > Double D: 920
>> > Triple D: 1120
>> >
>> > Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
>> >
>> > Without dominant trains:
>> > Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions Triple D: 
>> 290
>> > seconds / 114.9M Evaluations, 129.5M Predictions
>> > (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
>> >
>> > With dominant trains:
>> > Double D: 1 second / 323k Evaluations, 385k Predictions Triple D: 
>> 206
>>
>> seconds
>>
>> > / 87.4M Evaluations, 98.0M Predictions
>> > (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
>> >
>> > => Aliza Scenario 1856 B:
>> > 34 vertices with 50 edges
>> > 10 startvertices
>> >
>> > Values:
>> > Single D: 790
>> > Double D: 1280
>> > Triple D: 1440
>> >
>> > Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
>> >
>> > Without dominant trains:
>> > Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions Triple 
>> D: 3551
>> > seconds / 1473M Evaluations, 1709M Predictions
>> > (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
>> >
>> > With dominant trains:
>> > Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions Triple D: 
>> 1926
>> > seconds / 832M Evaluations, 962M Predictions
>> > (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
>> >
>> > => Scenario 1870:
>> > This is the route network used for testing a year ago,
>> >
>> > 23 vertices with 57 edges
>> > 1 startvertex
>> >
>> > Values:
>> > Single 12: 380
>> > Double 12: 690
>> > Triple 12: 820
>> >
>> > Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
>> >
>> > Without dominant trains:
>> > Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions Triple 
>> 12: 104
>> > seconds / 23.4M Evaluations, 61.6M Predictions
>> > (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
>> >
>> > With dominant trains:
>> > Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions Triple 
>> 12: 49
>> > seconds / 8.1M Evaluations, 30.0M Predictions
>> > (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
>>
>> 
>> ---------------------------------------------------------------------------
>> - --
>>
>> > uberSVN's rich system and user administration capabilities and 
>> model
>> > configuration take the hassle out of deploying and managing 
>> Subversion
>> > and the tools developers use with it. Learn more about uberSVN and 
>> get a
>> > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> 
>> ---------------------------------------------------------------------------
>> --- uberSVN's rich system and user administration capabilities and 
>> model
>> configuration take the hassle out of deploying and managing 
>> Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a 
>> free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------
>
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> End of Rails-devel Digest, Vol 45, Issue 12
> *******************************************

[Rails-devel] GameManager and players array problem (Java implementation of reordering players)

[Dr. M. B. <dr....@t-...>]

Hi Brett, Erik and Stefan et al. 

 

For the background information, 

 

1880 and a number of other games change the seat order after the starting or
in the starting round based on certain auction results.

 

Eric helped me to bring in a reorder routine in rails.game.gamemanager
called reorderPlayerByCash which should reorder the players array based on
their wallet.

 

This seems to function well inside the scope of the Roundclass and its
subclasses. 

 

But to my astonishment or Javanewbeeness the changed array players doesn't
show in the gameManager itself if you watch the array in debug mode outside
of the Roundclasses (i.e. rails.ui.swing.startwindow and Statuswindow). So
naturally the changed playerorder cant be accessed from that classes and
thus the changed seating order doesn't reflect it self in the ui. Whereas
the actions taken in the rounds are nevertheless credited right in the ui
display. This leads in a Stockround to the funny actions that Player A is
shown as active and upon acting his action leads to result for player C for
example.

 

So if anyone of you could point me at the silly simple (I assume) mistake in
my train of thought in implementing  the reordering I would be very
grateful.

 

Regards,

Martin