rails-devel

[Rails-devel] More about track-laying annoyances

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

I discovered this today from a game of 1835 in Rails 1.5.3.

Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
   M2 will be shown a possible build on the "dit" hex NE of Schwerin.
   M6 will not.

I suspect this is because the tile-suggesting logic assumes that a route which
visits the same hex twice (as the route from M6 to Schwerin visits Hamburg
again) is not considered a legal route for laying tiles.

I believe that is correct only in 18EU, so maybe it was written for that game.

At any rate it is one of many track-building rules which needs to be able to be
switched on or off for different games.

Re: [Rails-devel] More about track-laying annoyances

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

A second minor track-laying annoyance:

At the point of this save file, Marcus (running SX) uses the Pfalz to lay
a tile in Ludwigshafen/Mannheim.

Result: Marcus is asked where BA's home station should be placed.

There are two things wrong with that.  Kent is president of BA, so he, not
Marcus, should be asked.  And he should not be asked until BA's own turn
(so Marcus should not be allowed to place a SX token there on this turn,
even with Kent's approval).

Re: [Rails-devel] More about track-laying annoyances

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

On 2011-11-19 16:51, John David Galt wrote:
> I discovered this today from a game of 1835 in Rails 1.5.3.
> 
> Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
>    M2 will be shown a possible build on the "dit" hex NE of Schwerin.
>    M6 will not.
> 
> I suspect this is because the tile-suggesting logic assumes that a route which
> visits the same hex twice (as the route from M6 to Schwerin visits Hamburg
> again) is not considered a legal route for laying tiles.

Follow-up: This turns out not to be the real reason.  After laying tile 202 in
B12, the program still does not offer to let M6 build east of there.

Re: [Rails-devel] More about track-laying annoyances

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

Thanks for your test reports.
Again (you reported that issue before already) I cannot reconstruct that issue 
neither with the trunk version nor with 1.5.3 or 1.5.2 here.

So there are two things you could to help resolving that issue.
A) Save the game file and the log-file (18xx.log in the working directory of 
the running rails) and send it to me directly.
and/or 
B) Check if you can get the hex highlighted by moving the mouse around the map 
or zooming-in or zooming-out.

In a few cases I observed that none of the hexes that are be able to built is 
highlighted first, even if I have checked by the log that the route algorithm 
worked correctly. After moving around the cursor and/or zooming the hexes were 
highlighted. This seems to be a graphical glitch. 

I also wonder if anyone else experienced that before and if there is a 
systematic cause for it.

The algorithm for tile laying is not complete yet, however it already knows 
that in 1835 you are able to visit HH twice and that rules are different in 
other games.

Stefan


On Sunday, November 20, 2011 01:51:08 am John David Galt wrote:
> I discovered this today from a game of 1835 in Rails 1.5.3.
> 
> Given track connecting M2 - Schwerin delta - NE Hamburg - Kiel - M6,
>    M2 will be shown a possible build on the "dit" hex NE of Schwerin.
>    M6 will not.
> 
> I suspect this is because the tile-suggesting logic assumes that a route
> which visits the same hex twice (as the route from M6 to Schwerin visits
> Hamburg again) is not considered a legal route for laying tiles.
> 
> I believe that is correct only in 18EU, so maybe it was written for that
> game.
> 
> At any rate it is one of many track-building rules which needs to be able
> to be switched on or off for different games.
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] More about track-laying annoyances

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

The problem is that the BA had already floated and so, according to the
rules, the BA token had already been laid on the BA home hex L6.
Now that L6 is upgraded to green, that token must find a place.

The only easy way out of this problem I saw was to defer laying the BA home
token until its first OR turn -  in all cases. I hope that's an acceptable
workaround.

This change doesn't break any existing test cases, but your game will likely
be broken now, as well as any other 1835 games where a foreigner has laid a
tile on L6.

While testing this change, I found a problem with the earlier change to the
SellShares action, that caused some of my own test cases to be broken.
That's also fixed, and my new standard test cases had to be refreshed.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, November 20, 2011 3:02 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] More about track-laying annoyances
> 
> A second minor track-laying annoyance:
> 
> At the point of this save file, Marcus (running SX) uses the Pfalz to lay
a tile in
> Ludwigshafen/Mannheim.
> 
> Result: Marcus is asked where BA's home station should be placed.
> 
> There are two things wrong with that.  Kent is president of BA, so he, not
> Marcus, should be asked.  And he should not be asked until BA's own turn
> (so Marcus should not be allowed to place a SX token there on this turn,
> even with Kent's approval).

Re: [Rails-devel] More about track-laying annoyances

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

On 2011-11-22 15:45, Erik Vos wrote:
> The problem is that the BA had already floated and so, according to the
> rules, the BA token had already been laid on the BA home hex L6.
> Now that L6 is upgraded to green, that token must find a place.
> 
> The only easy way out of this problem I saw was to defer laying the BA home
> token until its first OR turn -  in all cases. I hope that's an acceptable
> workaround.

That's exactly what the rules say happens.