rails-devel — List for discussion of Rails development

Re: [Rails-devel] 2.0RC1 NPE when laying tile #445 in 18AL

[Nikolas Co <at...@at...>]

Having never worked with Rails until a couple hours ago, I'm not sure of
the accuracy of my diagnosis.

That said, I think the problem is that tile 445 should have a Stop
associated with its Station but does not; that is the immediate cause of
the NPE. The reason it doesn't have the expected Stop is because Rails
associates Stops with hexes. If there's a way for a tile lay to create a
Stop, tile 445 isn't using it.

I don't see how this could have worked in recent history… Searching the
mailing list archives turned up a similar from 2011-05-18, subject "18AL -
Lumber Terminal Tile lay issue", which makes me think this issue has
existed for years.

On Mon, Dec 21, 2015 at 3:23 PM Nikolas Co <at...@at...> wrote:

> Hm, the web archive is displaying my attached text file instead of my
> message. In case the message is mangled elsewhere:
> (My understanding is that rails-devel is the venue for detailed bug
> reports, so here we go…)
>
> In a game of 18AL, when a company attempts to use the ability of the
> private "Brown & Sons Lumber Co." (B&SLC), namely laying tile #445, it
> results in a NullPointerException. This is using Rails 2.0RC1. Save file
> and logs attached (rails_out.txt is the stdout+stderr, where the NPE is
> logged).
>
> I've simply confirmed that this is reproducible and haven't investigated
> for likely causes.
>
> On Sun, Dec 20, 2015 at 11:41 PM Nikolas Co <at...@at...> wrote:
>
>> (My understanding is that rails-devel is the venue for detailed bug
>> reports, so here we go…)
>>
>> In a game of 18AL, when a company attempts to use the ability of the
>> private "Brown & Sons Lumber Co." (B&SLC), namely laying tile #445, it
>> results in a NullPointerException. This is using Rails 2.0RC1. Save file
>> and logs attached (rails_out.txt is the stdout+stderr, where the NPE is
>> logged).
>>
>> I've simply confirmed that this is reproducible and haven't investigated
>> for likely causes.
>>
>

Re: [Rails-devel] 2.0RC1 NPE when laying tile #445 in 18AL

[Nikolas Co <at...@at...>]

Hm, the web archive is displaying my attached text file instead of my
message. In case the message is mangled elsewhere:
(My understanding is that rails-devel is the venue for detailed bug
reports, so here we go…)

In a game of 18AL, when a company attempts to use the ability of the
private "Brown & Sons Lumber Co." (B&SLC), namely laying tile #445, it
results in a NullPointerException. This is using Rails 2.0RC1. Save file
and logs attached (rails_out.txt is the stdout+stderr, where the NPE is
logged).

I've simply confirmed that this is reproducible and haven't investigated
for likely causes.

On Sun, Dec 20, 2015 at 11:41 PM Nikolas Co <at...@at...> wrote:

> (My understanding is that rails-devel is the venue for detailed bug
> reports, so here we go…)
>
> In a game of 18AL, when a company attempts to use the ability of the
> private "Brown & Sons Lumber Co." (B&SLC), namely laying tile #445, it
> results in a NullPointerException. This is using Rails 2.0RC1. Save file
> and logs attached (rails_out.txt is the stdout+stderr, where the NPE is
> logged).
>
> I've simply confirmed that this is reproducible and haven't investigated
> for likely causes.
>

[Rails-devel] 2.0RC1 NPE when laying tile #445 in 18AL

[Nikolas Co <at...@at...>]

log4j.configuration =  log4j.properties
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at net.sf.rails.algorithms.NetworkVertex.initRailsVertex(NetworkVertex.java:235)
	at net.sf.rails.algorithms.NetworkVertex.initAllRailsVertices(NetworkVertex.java:324)
	at net.sf.rails.algorithms.NetworkGraph.initRouteGraph(NetworkGraph.java:392)
	at net.sf.rails.algorithms.NetworkGraph.createRouteGraph(NetworkGraph.java:83)
	at net.sf.rails.algorithms.NetworkAdapter.getRouteGraph(NetworkAdapter.java:45)
	at net.sf.rails.ui.swing.ORUIManager.addGenericTokenLays(ORUIManager.java:323)
	at net.sf.rails.ui.swing.ORUIManager.defineTokenUpgrades(ORUIManager.java:304)
	at net.sf.rails.ui.swing.ORUIManager.setMapRelatedActions(ORUIManager.java:183)
	at net.sf.rails.ui.swing.ORUIManager.updateStatus(ORUIManager.java:1419)
	at net.sf.rails.ui.swing.ORUIManager.updateStatus(ORUIManager.java:1284)
	at net.sf.rails.ui.swing.GameUIManager.updateUI(GameUIManager.java:578)
	at net.sf.rails.ui.swing.GameUIManager.processAction(GameUIManager.java:345)
	at net.sf.rails.ui.swing.ORWindow.process(ORWindow.java:224)
	at net.sf.rails.ui.swing.ORUIManager.layTile(ORUIManager.java:719)
	at net.sf.rails.ui.swing.ORUIManager.confirmUpgrade(ORUIManager.java:653)
	at net.sf.rails.ui.swing.UpgradesPanel$1.actionPerformed(UpgradesPanel.java:82)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
	at java.awt.Component.processMouseEvent(Component.java:6516)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3312)
	at java.awt.Component.processEvent(Component.java:6281)
	at java.awt.Container.processEvent(Container.java:2229)
	at java.awt.Component.dispatchEventImpl(Component.java:4872)
	at java.awt.Container.dispatchEventImpl(Container.java:2287)
	at java.awt.Component.dispatchEvent(Component.java:4698)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
	at java.awt.Container.dispatchEventImpl(Container.java:2273)
	at java.awt.Window.dispatchEventImpl(Window.java:2719)
	at java.awt.Component.dispatchEvent(Component.java:4698)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:747)
	at java.awt.EventQueue.access$300(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:706)
	at java.awt.EventQueue$3.run(EventQueue.java:704)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:77)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.awt.EventQueue$4.run(EventQueue.java:718)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:77)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:717)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

[Rails-devel] RC2: 1880 tiles, upcoming end-of-the week

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

To all waiting for RC 2:

Sorry for the latest delay and my silence on the list. There has been a 
lot of other things occupying my time, so that I had no time to include 
the changes from Eric and check the reported bugs.

In addition I found out that a recent update from the TileDesigner 
master xml file to the Rails definition of tiles introduced some bugs 
into the 1880 tile definitions. Unfortunately I had not realized that 
Martin has changed/designed tiles outside of TileDesigner.

To make things worse, Martin and myself used different editors with 
different conventions how to indent xml-files. This makes the 
diff-output of the relevant git-commits difficult to interpret.

So I have to manually check the tile definitions of 1880 to make the 
route calculation work correctly.

I have to admit that this was a frustrating experience, it is not the 
first time that this process of tile-creation creates a lot of manual 
work. From my perspective this has to be solved before I start to add a 
new game to Rails from scratch. So most likely this will be my next task 
to re-work the tile definition process.

However my first task is to get RC 2 out of the door this week so that 
Rails 2.0 will be released this year.

Stefan

Re: [Rails-devel] 1880: Errors in route calculation

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

Hi Oliver,
thanks for your bug report.

Unfortunately there has been several bugs in 1.9.0 implementation of the 
Express-Trains modifier some wrong tile and train definitions.

Nearly all of them are already fixed in RC 1, however a few wrong tile 
definitions sneaked in again.

See my next mail for more details about RC 2.

Stefan


On 12/05/2015 07:19 PM, Oliver Heck wrote:
> Hi,
>
> we encounter a lot of errors in route calculation in 1880 using rails 1.9.0
>
> I am attaching an example where a small station is ignored.
>
> Any idea what's going wrong here?
>
> Cheers,
> Oliver
>
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] 1880: Errors in route calculation

[Oliver H. <oli...@gm...>]

Hi,

we encounter a lot of errors in route calculation in 1880 using rails 1.9.0

I am attaching an example where a small station is ignored.

Any idea what's going wrong here?

Cheers,
Oliver

Re: [Rails-devel] new bug with 1856 bonuses in rails 1.9 and later + partial fix

[games.bazin <gam...@or...>]

(Sorry, previous msg again sent in bogus format. I'm sending again as raw txt + I'm adding partial debuging info.)

Hello all.

I made some further research on this new 1856 bonus bug.

The situation before the first T5 is bought is :
GW and GT have the bridge bonus, one bridge bonus still available from GW (GW had initially purchased the bridge company)
LPS, CA and BBG have the tunnel bonus, no further tunnel available (LPS had initially purchased the tunnel company)

After the T5 is bought : normal behaviour :
bridge bonus is available from bank
tunnel bonus is not available

Bug situation appears after CGR formation. GW, GT, LPS, CA and BBG merge into CGR.

== in 1.9 :
CGR has 1 bridge and 1 tunnel
tunnel is available from LPS (!)
bridge is available from bank

== in 2.0RC1 and in origin/rails_2_develop and in origin/rails_2_maintenance :
CGR has 2 bridges and 2 tunnels (!) (duplicate bonus token is a known bug ; what is semi-surprising here is that CGR only gets 2 and not 3 tunnel bonuses)

bridge is available from bank
tunnel is available from LPS (!)


== in origin/eba_r2dev thank's to Stefan's last bug correction (*), the situation is a little different but still buggy :

CGR has 1 bridge and 1 tunnel (correct behaviour)
bridge is available from bank
tunnel is not available at all (it should be available from bank)

(*) i'm refering to :
daca42d adapted the change for removal of bonus tokens, still based on name/value, renamed equals to equalsBonus method


=> This is a result of two different bugs in the code if i'm not mistaken

1) in CGRFormationRound.java 
at some point in the code there is : 

if (sp.getId().equalsIgnoreCase(bonus.getName())) {
sp.makeResellable();
log.debug("BonusToken "+bonus.getName()+" made sellable again");
break;
}

The bug is that the condition in the if is always false and the bonus is never made sellable again.
The "if" should be :

if (sp.getName().equalsIgnoreCase(bonus.getName())) {
sp.makeResellable();
log.debug("BonusToken "+bonus.getName()+" made sellable again");
break;
}

If tested with this new code, origin/eba_r2dev reverts to 1.9 behaviour : 
CGR has 1 bridge and 1 tunnel (correct behaviour)
bridge is available from bank
tunnel is available from LPS (!)

2) The source of the "LPS instead of bank" bug comes from the buyTrain() function in OperatingRound_1856.java, at the first time a T5 train is bought.

There, 
if (postPhase.getId().equals("5")) {
// Make Bridge and Tunnel tokens buyable from the Bank.
for (SpecialProperty sp : gameManager.getCommonSpecialProperties()) { // EBA debug inserted here
if (sp instanceof SellBonusToken) {
SellBonusToken sbt = (SellBonusToken)sp;
// FIXME: Is it ipo or pool portfolio?
// Assume it is pool
sbt.setSeller(bank.getPool());
log.debug("SP "+sp.getId()+" is now buyable from the Bank");
}
}

The issue in this situation is that the "for" loop on SpecialProperty sp runs only once, for the bridge, but not for the tunnel.
I inserted a debug in the "for" loop to doublecheck, before the "if", and the for ran only once.
However, I'm not yet fluent enough in the code and in java to debug the gameManager.getCommonSpecialProperties() part.

Hope it helps


Note1 : to reproduce the bug, use the attached file. This is a 1.9 save file just before CGR creation. Then proceed with CGR creation (done, none, none, ok, none)
Note2 : the first T5 in this game is bought in OR5.1 by the THB
Eric.

Re: [Rails-devel] new bug with 1856 bonuses in rails 1.9 and later

[games.bazin <gam...@or...>]

Hello all.

I made some further research on this bug.

The situation before the first T5 is bought is : 
GW and GT have the bridge bonus, one bridge bonus still available from GW (GW had initially purchased the bridge company)
LPS, CA and BBG have the tunnel bonus, no further tunnel available (LPS had initially purchased the tunnel company)

After the T5 is bought : normal behaviour :
bridge bonus is available from bank
tunnel bonus is not available

Bug situation appears after CGR formation. GW, GT, LPS, CA and BBG merge into CGR.

in 1.9 : 
CGR has 1 bridge and 1 tunnel
tunnel is available from LPS (!)
bridge is available from bank

in 2.0RC1 and in origin/rails_2_develop and in origin/rails_2_maintenance :
CGR has 2 bridges and 2 tunnels (!) (duplicate bonus token is a known bug ; what is semi-surprising here is that CGR only gets 2 and not 3 tunnel bonuses)

bridge is available from bank
tunnel is available from LPS (!)


in origin/eba_r2dev thank's to Stefan's last bug correction (*), the situation is a little different but still buggy :

CGR has 1 bridge and 1 tunnel (correct behaviour)
bridge is available from bank

tunnel is not available at all (it should be available from bank)

 

(*) i'm refering to :

daca42d adapted the change for removal of bonus tokens, still based on name/value, renamed equals to equalsBonus method

 

Note : to reproduce the bug, use the attached file. This is a 1.9 save file just before CGR creation. Then proceed with CGR creation (done, none, none, ok, none)

 

 

Eric.

 

 


> Message du 11/11/15 02:19
> De : rai...@li...
> A : rai...@li...
> Copie à : 
> Objet : Rails-devel Digest, Vol 90, Issue 3
> 
> Hello all.
> 
> I found a new bug in rails 1.9 (playing 1856). Save file is attached.
> Can't tell if it exists in 2.0RC1 as I cannot load the 1.9 save file in 2.0RC1 (loading halts at 92% as already reported)
> Maybe Stefan if you can find a way to load the save file in the soon to be 2.0RC2 you can check if the bug still exists or not ?
> 
> So here's the bug : we are after CGR formation, and in the Special menu, CV can buy 
> - tunnel from LPS (!)
> - bridge from bank
> but LPS no longer exists (has merged into CGR).
> 
> If CV buys from the "LPS", it's cash decreases by $50 as expected, but bank's cash is unchanged.
> 
> Regards,
> Eric.
> 
>
> [ 1856_20151110_1901_Eric (tunnel LPS bug).rails (34.6 Ko) ]

[Rails-devel] new bug with 1856 bonuses in rails 1.9

[games.bazin <gam...@or...>]

Hello all.

I found a new bug in rails 1.9 (playing 1856). Save file is attached.
Can't tell if it exists in 2.0RC1 as I cannot load the 1.9 save file in 2.0RC1 (loading halts at 92% as already reported)
Maybe Stefan if you can find a way to load the save file in the soon to be 2.0RC2 you can check if the bug still exists or not ?

So here's the bug : we are after CGR formation, and in the Special menu, CV can buy 
- tunnel from LPS (!)
- bridge from bank
but LPS no longer exists (has merged into CGR).

If CV buys from the "LPS", it's cash decreases by $50 as expected, but bank's cash is unchanged.

Regards,
Eric.

[Rails-devel] strange bug on 2.0RC1+

[games.bazin <gam...@or...>]

(re-sending as raw text my previous message that didn't go well on the list the first time - sorry for the doublepost)

Hello Stefan and all.

I found a strange bug but maybe it's only my mistake. I'm posting just in case.
I wanted to play a 2-player 1856 game with my son, with as much bug fixed as possible, so what I did is :

- I imported the last commit that Stefan had put on origin/rails_2_maintenance (this was earlier friday ; I see that you have put one more commit now) into my local eba_r2dev (with the fix of the duplicate token in CGR). So it was a "2.0RC1+" setup and it looked like this :

$ git log -n 6 --oneline
fde97fc Merge remote-tracking branch 'origin/rails_2_maintenance' into eba_r2dev
22f2b8e Proposal for a fix of the duplicate tunnel/bridge bonus in 1856 CGRFormationRound
e485235 fixed bug for semi-restrictive tile laying, that only one of the base tokens is considered for routing
d0185de Merge recent changes from 'rails_2_maintenance' into rails_2_develop
7477c48 fixed reload and press done button bug in 1856
a8caa0b quick fix to remove token of ship company in 1856 in phase 5 (first 6 train), this is related to name and realName attributes of Phase

- not knowing how to build a jar file, i then loaded the resulting git directory into eclipse and started the game from there. 

All started fine but with this setup I found a strange bug (see attached save file) : only one of GW's train is taken into account to compute company's revenues, instead of two.
Note that if loading the same save file into the regular 2.0RC1, the two trains of GW are correctly taken into account so it's linked to the combination of commits I have in my current local eba_r2dev.

Now, I'm not sure if there is really an underlying issue with this combination of commits, or if it's not a real bug but my trying to play the apprentice sorcerer :)
Please let me know.

Eric

[Rails-devel] strange bug on 2.0RC1+

[games.bazin <gam...@or...>]

Hello Stefan and all.

 

I found a strange bug but maybe it's only my mistake. I'm posting just in case.

I wanted to play a 2-player 1856 game with my son, with as much bug fixed as possible, so what I did is :

 

- I imported the last commit that Stefan had put on origin/rails_2_maintenance (this was earlier friday ; I see that you have put one more commit now) into my local eba_r2dev (with the fix of the duplicate token in CGR). So it was a "2.0RC1+" setup and it looked like this :

 

$ git log -n 6 --oneline
fde97fc Merge remote-tracking branch 'origin/rails_2_maintenance' into eba_r2dev
22f2b8e Proposal for a fix of the duplicate tunnel/bridge bonus in 1856 CGRFormationRound
e485235 fixed bug for semi-restrictive tile laying, that only one of the base tokens is considered for routing
d0185de Merge recent changes from 'rails_2_maintenance' into rails_2_develop
7477c48 fixed reload and press done button bug in 1856
a8caa0b quick fix to remove token of ship company in 1856 in phase 5 (first 6 train), this is related to name and realName attributes of Phase

 

- not knowing how to build a jar file, i then loaded the resulting git directory into eclipse and started the game from there. 

 

All started fine but with this setup I found a strange bug (see attached save file) : only one of GW's train is taken into account to compute companie's revenus, instead of two.

Note that if loading the same save file into the regular 2.0RC1, the two trains of GW are correctly taken into account so it's linked to the combination of commits I have in my current local eba_r2dev.


Now, I'm not sure if there is really an underlying issue with this combination of commits, or if it's not a real bug but my trying to play the apprentice sorcerer :)

Please let me know.

[Rails-devel] #173 18EU red-to-red bonus incorrect

[Jim K. <jam...@bt...>]

Hello All, 

I note this ticket is still open (from version 1.8x). 

This is where the bonus is implemented where there is only one red off-board are at the end of the route but, runs through Hamburg which is not at the end of said route.

Will this be fixed in v2.x?

Cheers,

Jim Knight

Sent from Mail for Windows 10


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [Rails-devel] Proposal for a fix of the duplicate tunnel/bridge bonus in 1856 CGRFormationRound on github

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

Eric:
yes you succeeded in committing and pushing your fix. Thumb up!

And you caught the essence of the problem, the comparison with equals 
does not work anymore.

However I will change your commit a little bit, as I introduced the bug 
by not carefully change the function calls during creation of the Bonus 
objects.

Stefan


On 11/02/2015 06:24 PM, games.bazin wrote:
> Hello Stefan and all
>
> I'm switching to rails-devel as indicated.
>
> I think i managed to pull my own branch eba_r2dev on github.  Please let
> me know if it worked and i you can see there my first commit with a
> Proposal for a fix of the duplicate tunnel/bridge bonus in 1856
> CGRFormationRound in it.
>
> Thank's Stefan for your continued support.
>
> If it worked, i'll be happy (for someone who didnt know a word about git
> and java a week ago)
>
> If it failed, well, i'll keep trying :)
>
> Eric
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] 1880 tiles and tiles in general

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

Martin:
as I discovered in preparation of my move for the BGG game of 1880, 
there are some tiles with wrong values.

I found the yellow OO (235) and Shanghai (8877) tiles, however there 
might be more.

Some of the mess I created myself by updating the tile information for 
1880 of Rails from the TileDesigner files. This was part of my addition 
of tiles for 18NL.

As you told me in Essen you have recently by-passed the TileDesigner and 
created/changed the files directly and so I overwrote those changes 
without knowing.

There is some process setup for manually changed files (see for example 
HandmadeTiles.xml in folder /src/main/resources/tiles).

The short-term solution is:

I will check, which tiles in 1880 are effected and change them 
accordingly and those changes will be included in upcoming RC 2.
I still have to  wait for broadband access at home, anyway ... :-(

However we need to change that process if we want to be able to cover 
more titles with less effort.

Maybe we should do a "sprint" type of meeting (I would offer to travel 
to Bremen for that) to discuss how a suitable definition of tiles for 
Rails could look like and start some hacking on a Java package that 
creates the visual components out of those definitions. This would even 
allow us to bypass the SVG tiles and make a potential Android support 
much easier.

What is your opinion?

Stefan

[Rails-devel] Proposal for a fix of the duplicate tunnel/bridge bonus in 1856 CGRFormationRound on github

[games.bazin <gam...@or...>]

Hello Stefan and all

 

I'm switching to rails-devel as indicated.

I think i managed to pull my own branch eba_r2dev on github.  Please let me know if it worked and i you can see there my first commit with a Proposal for a fix of the duplicate tunnel/bridge bonus in 1856 CGRFormationRound in it.

 

Thank's Stefan for your continued support.

If it worked, i'll be happy (for someone who didnt know a word about git and java a week ago)

If it failed, well, i'll keep trying :)

 

Eric

Re: [Rails-devel] [Rails-users] 2.0RC1 cannot lay tile + mapcorrection issue with reload

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

Eric:

Thanks for your further investigation. This is great help.

Most likely the issue for loading is related to the other bug/anomaly 
you reported earlier, which I have fixed in rails_2_maintenance already.

However I still have to check that.

I will built a release candidate 2 soon, however I have troubles with my 
internet access from home, so I have to postpone the up-loading.

Stefan

And to avoid annoying the subscribers to Rails-user:
Could you please further report bugs on Rails-devel instead of 
Rails-users. Rails-users is not intended for (frequent and detailed) bug 
reporting.


On 11/01/2015 12:11 PM, games.bazin wrote:
> Hello all
>
> Some more bug reports following this issue.
>
> 1) bug with map correction
>
> from the situation in 1856_20151031_1804_GW-E16toCA.rail, you can use
> map correction to continue the game as it should by laying #24 in E16
> with orientation SE.
>
> File 1856_20151101_aftermapcorrection.rails is a save after GW finishes
> its turn and next company starts to play.
>
> However, 2.0RC1 cannot load from that moment : loading
> 1856_20151101_aftermapcorrection.rails or any later save file results in
> an "interrupted load" just before the map correction.
>
> 2) In order to further play the game (and to further test), we have
> decided to check how the game behaves on 1.9.0
>
> However, file 1856_20151031_1804_GW-E16toCA.rail (legit 2.0RC1 file
> before map correction) could not be loaded on 1.9.0.   Maybe that's
> normal and files are not backward compatible ?
>
> So, we have restarted the game from scratch in 1.9.0
>
> The resulting 1.9.0 file is attached as 1856_20151101_1019_GWbug.rails
>
> Result :
>
> - from that postion, 1.9.0 allows to lay #24 in E16 with orientation SE
> (normal behaviour)
>
> - the file 1856_20151101_1019_GWbug.rails can be reloaded in 2.0RC1, and
> from that same position, 2.0RC1 forbids to lay #24 in E16 with
> orientation SE
>
> Eric
>
>      > Message du 31/10/15 21:12
>      > De : "games.bazin" <gam...@or...>
>      > A : rai...@li...
>      > Copie à :
>      > Objet : 2.0RC1 cannot lay tile
>      >
>      >
>
>      > Hello all
>
>      >
>
>      > I found what looks like a strange bug in 2.0RC1 - took place in
>     1856 but doesn't seem 1856 related. Please see attached save file.
>
>      > GW should be able to lay a green tile #24 in E16 going from it's
>     starting position to CA's starting position, and is not allowed to
>     do so by the game.
>
>      > More precisely, 2.0RC1 allows #24 in E16 with orientation NW
>     (which is normal) but forbids the opposit orientation, which is not
>     normal.
>
>      >
>
>      > Eric
>
>
>      >
>      > [ 1856_20151031_1804_GW-E16toCA.rails (16.8 Ko) ]
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users
>

Re: [Rails-devel] [Rails-users] 2.0RC1 cannot lay tile

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

This bug is fixed in rails_2_maintenance.


On 10/31/2015 10:37 PM, Stefan Frey wrote:
> Eric:
> thanks for catching this bug.
>
> 1856 is semi-restrictive for tile lays, thus there is a check involved
> if any of the new track segments is reachable from any station marker
> for the company laying the tile.
>
> Due to some reason only one of the two tokens for GW is considered. And
> interestingly if one tries to make the same tile lay for LPS only the
> reversed orientations are allowed.
>
> This indicates that the current check somehow only uses one of the
> tokens and not all of the tokens, which might help to find the true reason.
>
> I hope I will get some time tomorrow to look into that.
>
> Stefan
>
>
> On 10/31/2015 09:12 PM, games.bazin wrote:
>> Hello all
>>
>> I found what looks like a strange bug in 2.0RC1 - took place in 1856 but
>> doesn't seem 1856 related. Please see attached save file.
>>
>> GW should be able to lay a green tile #24 in E16 going from it's
>> starting position to CA's starting position, and is not allowed to do so
>> by the game.
>>
>> More precisely, 2.0RC1 allows #24 in E16 with orientation NW (which is
>> normal) but forbids the opposit orientation, which is not normal.
>>
>> Eric
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Rails-users mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-users
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] [Rails-users] 2.0RC1 cannot lay tile

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

Eric:
thanks for catching this bug.

1856 is semi-restrictive for tile lays, thus there is a check involved 
if any of the new track segments is reachable from any station marker 
for the company laying the tile.

Due to some reason only one of the two tokens for GW is considered. And 
interestingly if one tries to make the same tile lay for LPS only the 
reversed orientations are allowed.

This indicates that the current check somehow only uses one of the 
tokens and not all of the tokens, which might help to find the true reason.

I hope I will get some time tomorrow to look into that.

Stefan


On 10/31/2015 09:12 PM, games.bazin wrote:
> Hello all
>
> I found what looks like a strange bug in 2.0RC1 - took place in 1856 but
> doesn't seem 1856 related. Please see attached save file.
>
> GW should be able to lay a green tile #24 in E16 going from it's
> starting position to CA's starting position, and is not allowed to do so
> by the game.
>
> More precisely, 2.0RC1 allows #24 in E16 with orientation NW (which is
> normal) but forbids the opposit orientation, which is not normal.
>
> Eric
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users
>

[Rails-devel] Update on next 2.0 RC release

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

All:
Recent weeks were pretty busy on my side, however I have some spare time 
available now, so my intention is to get RC2 out of the door in the next 
few days. Most likely this will be the latest RC and the official 2.0 
release is possible next week.

My work will then focus on 2.1, the refactoring of the StockRound 
classes and help Martin getting 1844/54/37 fully supported.

Other games that wait for the StockRound refactoring are 1825 and 1870, 
so expect them to be finalized in the mid-term future.

Stefan

Re: [Rails-devel] [Rails-users] Bugs and wishlist for 1856 on rails 1.9.0 - new tests on 2.0RC1

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

Eric:
thanks for the save files and your detailed reports.

See my comments below, prefixed with "SFY".
I will add them to the roadmap/bug-list on github later.

Stefan

 > anomaly 1 : the +20 bonus from the port disapears when the first T5 
train,
while it should only disapear when T6 is bought
John : I believe you're correct, this is a bug which has always been there.

=> Still present in 2.0.RC1.   Exemple available in SR5.1 when CA plays. 
  If
this can be fixed that would be nice.  Workaround available through manual
revenue adjustment.

SFY: There was a fix by Erik Vos on 3/9/10 that changed the phase from 6 
to 5.
The commit comment is: "Fixed port token removal phase (5, was 6)". For 
some
reason Erik assumed that the correct phase is 5. It can be changed via a
parameter in xml, thus it is easy to fix.

Some more details, how this happened:
The rules state: "This port token may be placed during any operating round
in phase two or three and is removed at the beginning of phase five."

The issue now is that 1856 calls the phases by "train-number
minus one". Thus on purchase of the 6-train phase 5 starts.

To add to the confusion the 1856 configuration file contains two phase 
name definitions.
One is called "name", the other "realName". For phase 5 in 1856 they are 
set as name="6", realName="5".

Why this is/was required, has to be checked. Most likely due to legacy 
reasons, as
some time ago the phase changes were hard-coded against the phase names.
However this changed and now phase changes can be setup manually.


 > anomaly 2 : situation : company A must buy a train and decides to it 
from
company B. (lets say a T4 for example). Assume company A has only $100 
in cash.
Rails displays a text like : "you may add up to $250" (i.e. difference 
between
T4 nominal value and cash availble in A). But according to the rules, the
president may not add money to buy a train if company A buys from 
company B,
only if it buys from Bank or Open Market

SFY: Forced train buying varies between games. There are some options 
already,
however (as shown here) not everything is covered.
I will look into this issue as soon as I refactor the operating round in 
later
releases (however most likely not before 2.2).

 > anomaly 3 : situation : at CGR formation, GW has 3 loans and posseses 
only
$34 in cash. According to the rules, the president should only be 
offered the
choice of 0 or 3, but not values in between (1 or 2 are not allowed in this
situation).

Confirmed by John to be minor bugs.

=> Still present in 2.0.RC1.   Both not a real issue as you can  still 
play by
the rules by not using the offered possibilities.  So should be fixed in an
ideal world, but no urgency. I prefer that you work on the wishlist at 
the end
of this mail :)

SFY: CGR Formation round is up to refactoring soon, most likely with the 
other
Nationalization Rounds (1835, 1837). Will put that on the list to fix.


 > anomaly 4 : seen in both games on 1.9.0 : company tokens are not 
properly
displayed on the gray toronto tile #124

=> no longer present in 2.0.RC1 where tokens are properly displayed on 
the gray
toronto tile #124.  Anomaly solved.

SFY: Yes this was fixed recently for 2.0.

 > anomaly 5 : seen on 1.9.0 : situation : during the operating round of 
company
A, his president must sell [shares of] company B to raise money 
according to
forced sale rule. As a result, this changes the position of company B on 
the
stock market (drops to lower values), but 1.9.0 doesnt update the company
operating order (behaves has if B was still in it's original position 
before
the sale)

john : I haven't seen this. If it happens it is a bug.

=> I haven't tested yet if this can be replicated on 2.0RC1 yet.  Will 
let you
know.

SFY: Would be interested for a test file for that. Company ordering
might not updated in all cases required. A potential solution is to use 
a trigger.


 > anomaly 6 : seen on 1.9.0 : 1.9.0 doesnt update the certificate limit
according to the new (lower) number of available companies when one 
companie
disapears during OR.

john : Good catch! This is a bug. Steve Thomas's FAQ for the game agrees

=> I haven't tested yet if this can be replicated on 2.0RC1 yet.  Will 
let you
know.

SFY: Again: would be interested for a test file for that. Certificate 
limit checks
might not update in all cases. A potential solution is to set a trigger.

 > anomaly 7 : seen on 1.9.0 : situation : during stock round, before the
purchase of the first T6, player's worth is sometime wrongly displayed 
at the
begining of the stock round. The issue disapears if you save and reload the
game.

=> I could not reproduce the issue on 2.0RC1.   However, I found other 
display
issues, see Anomaly 10 below.


SFY: Players worth calculation is updated for 2.0, thus it should now 
cover all cases.
Otherwise it is a bug. In 1.x it did not update in all cases.

 > anomaly 8 : situation : bankrupcy. during an operating round, forced 
sales,
the president has $63 cash, must raise more cash but cannot sell anything.
rails ends leaving $63 in the president's cash and worth, while 
according to
the rules, the president's cash should be reduced to 0
John : This is a bug, and probably applies to most or all games, not 
just 1856.

=> reproduced in 2.0.RC1.   In fact, the issue in this situation is that 
the
game doesn't really complete bankrupcy as it expects the president to sell
something but nothing is available for sale.   So the game becomes stuck.

SFY: Good catch, if this happens. I have to re-create that situation for 
2.0.
Should be fixed before 2.0 release.

 > anomaly 9 :  my mistake.  I made again the computation when replaying 
the
game and rails if correct, I was wrong in my pbem.  Forget this one :)

SFY: Ok, good to know, that it does not occur.

 > Anomaly 10 : display issue and corrupted save files.

SFY: Will reply to that in a separate, later mail, needs more investigation.


 > [wishlist] 1 :Add a more general moderator option that allows to 
transfer
shares between bank and open market and player, and that allows to 
change the
position of the shares on the open market.
John : I agree. Allow any certificate to be moved between any two hands.

=> Two uses for this : allow to continue the game after a bug or a former
misclick, and allow to accomodate for local rules (i.e. my team plays with
slightly different version of CGR share allocation during CGR formation, 
this
would allow us to adapt the repartition given by the official rules).


SFY: Asset correction is on my to-do-list for a long time.

This is much easier to implement for 2.0, given the new portfolio structure.

However it still has to be written, and there are many other things to do.
In any case it could be a good start for someone who starts working on 
Rails, as
there is no need to change any of the core classes.
My own first code added to Rails were Map and Cash Correction.

 > [wishlist] 2 : During the stock round, in the game status - stock round
window, add a "-" to indicate that a player has already sold from a given
company.

=> I saw that something similar (pink background color) was implemented in
2.0RC1, that's great thanks !

SFY: Yes. ;-)

new wishlist based on 2.0RC1 experience :

[wishlist] 3 : when a company enters the brown area, it's background 
color in
the strock round window becomes brown (good idea) but that brown is much to
dark and prevents reading the share value.  Please use a less dark brown

SFY: Yep, good idea, should be changed soon.
That should be possible, however it should be the same color is in stock 
market.
I assume that we need to adjust the foreground color for fields based on the
background colors (there is an algorithm that switches foreground color 
to white,
as soon as the background gets dark).


[wishlist] 4 : I like to play the OR with the OR map in full screen.  This
works well.

I'd like to do the same thing with the status map during the SR, but it 
keeps
receizing to a smaller size after each action. Very annoying.

SFY: Yep, good idea. Should be changed soon.

[wishlist] 5 : when company A buys a train from company B, user is 
promted for
the amount payed by A.

Allow the user to specify a negative number, like "-x" meaning : all 
cash from
A but $x

Allow the user to specify 0, meaning : all the cash from A

SFY: Yep, good idea: Should be changed soon.

[wishlist] 6 : during OR, once you have selected a tile to be placed, 
you must
click on LayTile (and then very often on Skip as you dont lay a new token).

Nearly all buttons have a keyboard shortcut but LayTile and Skip don't. 
  Please
add a keyboard shortcut to each.

SFY: Yep, good idea: Should be changed soon.


[wishlist] 7 : please add an option so that the game automatically 
generates a
save file at the end of each company turn during Operating Rounds, and 
at the
end of each Player6 action during Stock Rounds.  I dont mind filling my 
disk (i
can clean it after with a few clicks) but I would like to be sure i can 
revert
to a recent save if my computer crashes for any reason.


SFY: There is an option to autosave (saves after each action).

As each save file contains the complete game history, it would be easier 
(and
more powerful) to provide a selection for the user to jump to the start 
of each
stock/operating round and then to each player activity.

Again mostly a matter of implementation resources, and potentially good 
task for someone
who wants to start coding on Rails.

Re: [Rails-devel] [SPAM] Fw: new message

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

This user has been unsubscribed from the list for spamming malware links.​

PLEASE DO NOT CLICK THE LINKS.

---Brett.

Re: [Rails-devel] Rails 2.0 RC1 1835 bug

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

I did check the code and it does explicitly store the prussian starting 
player (thus the owner of M2) for later (merging) rounds.

Maybe Erik could answer, if he consulted a version of 1835 rules that 
works like that?

Unfortunately fixing that bug potentially invalids (some of) the test 
games for 1835, so I am a little reluctant to fix that issue for the 
upcoming 2.0 release. In most cases the order of merging the privates is 
not very important for game play, so it is not that critical.

My preference is to fix that in rails_2_develop as soon as I have added 
the code to save Rails files as json files. This would allow to edit the 
save files manually and quickly fix them. So most likely it will be 
fixed in 2.1 or 2.2.

We have to address that code anyway to make it compatible with 1837, the 
current implementation does not look very undo-safe anyway.

Stefan


On 10/18/2015 12:58 PM, Stefan Frey wrote:
> Both rules I checked agree on that the first player to ask is the one
> holding the priority.
> This is a bug in RC 1, most likely in 1.x as well.
>
> I did and have some fixes for player order in the queue (see recent 1880
> bug), so I will include that too.
>
> Anyone knows what the respective 1837 ruling is?
>
>
>
>
> "Schnell, Volker" <volker.schnell <http://volker.schnell>@arcor.de>schrieb:
>
>     I meant the player with the priority Deal. (in the German Rules
>     "startspieler")
>     Volker
>
>     Am 18.10.2015 um 00:41 schrieb John David Galt:
>      > On 2015-10-17 13:13, Schnell, Volker wrote:
>      >> a little bug in Rails 20. RC1.
>      >> The Pru was started in the Operating round. 4 Minors (M3, M5, BB
>     and HB)
>      >> were not exchanged.
>      >>
>      >> At the End of the operating Round all owning Players are asked, to
>      >> exchange or not.
>      >> Rails starts with the actual President. see attached Picture.
>     (ie. Sven)
>      >>
>      >> The Rules states, it begins with the starting Player. (Klaus-Jürgen)
>      > By "starting player" do you mean the player with the
>     Erstkaufsrecht? Or
>      > the player who had it at the beginning of the game?
>      >
>      > I have always played (interpreted) this rule to mean that each
>     round of
>      > conversions starts with the former owner of M2, who is usually (not
>      > always) the president of PR.
>      >
>      >
>     ------------------------------------------------------------------------------
>      > _______________________________________________
>      > Rails-devel mailing list
>      > Rai...@li...
>      >https://lists.sourceforge.net/lists/listinfo/rails-devel
>     <https://lists.sourceforge.net/lists/listinfo/rails-devel>
>
>     --
>     Volker Schnell
>     email: vol...@ar...
>     homepage: home.arcor.de\volker_schnell
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Rails-devel mailing list
>     Rai...@li...
>     https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 2.0 RC1 1835 bug

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

<html><head>
  
  <meta name="viewport" content="width=device-width" /><meta http-equiv="Content-Type" content="text/html;charset=utf-8" /></head><body>Both rules I checked agree on that the first player to ask is the one holding the priority. <br>
This is a bug in RC 1, most likely in 1.x as well. <br>
<br>
I did and have some fixes for player order in the queue (see recent 1880 bug), so I will include that too.<br>
<br>
Anyone knows what the respective 1837 ruling is? <br>
<br><br><div class="gmail_quote"><br>
<br>
&quot;Schnell, Volker&quot; &lt;<a href="http://volker.schnell">volker.schnell</a>@arcor.de&gt;schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

  
    I meant the player with the priority Deal. (in the German Rules<br />
    &quot;startspieler&quot;)<br />
    Volker<br />
    <br />
    Am 18.10.2015 um 00:41 schrieb John David Galt:<br />
    &gt; On 2015-10-17 13:13, Schnell, Volker wrote:<br />
    &gt;&gt; a little bug in Rails 20. RC1.<br />
    &gt;&gt; The Pru was started in the Operating round. 4 Minors (M3, M5, BB and HB)<br />
    &gt;&gt; were not exchanged.<br />
    &gt;&gt;<br />
    &gt;&gt; At the End of the operating Round all owning Players are asked, to<br />
    &gt;&gt; exchange or not.<br />
    &gt;&gt; Rails starts with the actual President. see attached Picture. (ie. Sven)<br />
    &gt;&gt;<br />
    &gt;&gt; The Rules states, it begins with the starting Player. (Klaus-J&uuml;rgen)<br />
    &gt; By &quot;starting player&quot; do you mean the player with the Erstkaufsrecht? Or<br />
    &gt; the player who had it at the beginning of the game?<br />
    &gt;<br />
    &gt; I have always played (interpreted) this rule to mean that each round of<br />
    &gt; conversions starts with the former owner of M2, who is usually (not<br />
    &gt; always) the president of PR.<br />
    &gt;<br />
    &gt; ------------------------------------------------------------------------------<br />
    &gt; _______________________________________________<br />
    &gt; Rails-devel mailing list<br />
    &gt; Rai...@li...<br />
    &gt;<a href="https://lists.sourceforge.net/lists/listinfo/rails-devel" target="_blank"> https://lists.sourceforge.net/lists/listinfo/rails-devel</a><br />
    <br />
    --<br />
    Volker Schnell<br />
    email: vol...@ar...<br />
    homepage: home.arcor.de\volker_schnell<br />
    <br />
    <br />
    ------------------------------------------------------------------------------<br />
    _______________________________________________<br />
    Rails-devel mailing list<br />
    Rai...@li...<br />
    <a href="https://lists.sourceforge.net/lists/listinfo/rails-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/rails-devel</a><br />
  
</blockquote></div></body></html>

Re: [Rails-devel] Rails 2.0 RC1 1835 bug

[Schnell, V. <vol...@ar...>]

I meant the player with the priority Deal. (in the German Rules 
"startspieler")
Volker

Am 18.10.2015 um 00:41 schrieb John David Galt:
> On 2015-10-17 13:13, Schnell, Volker wrote:
>> a little bug in Rails 20. RC1.
>> The Pru was started in the Operating round. 4 Minors (M3, M5, BB and HB)
>> were not exchanged.
>>
>> At the End of the operating Round all owning Players are asked, to
>> exchange or not.
>> Rails starts with the actual President. see attached Picture. (ie. Sven)
>>
>> The Rules states, it begins with the starting Player. (Klaus-Jürgen)
> By "starting player" do you mean the player with the Erstkaufsrecht?  Or
> the player who had it at the beginning of the game?
>
> I have always played (interpreted) this rule to mean that each round of
> conversions starts with the former owner of M2, who is usually (not
> always) the president of PR.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Rails 2.0 RC1 1835 bug

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

On 2015-10-17 13:13, Schnell, Volker wrote:
> a little bug in Rails 20. RC1.
> The Pru was started in the Operating round. 4 Minors (M3, M5, BB and HB)
> were not exchanged.
> 
> At the End of the operating Round all owning Players are asked, to
> exchange or not.
> Rails starts with the actual President. see attached Picture. (ie. Sven)
> 
> The Rules states, it begins with the starting Player. (Klaus-Jürgen)

By "starting player" do you mean the player with the Erstkaufsrecht?  Or
the player who had it at the beginning of the game?

I have always played (interpreted) this rule to mean that each round of
conversions starts with the former owner of M2, who is usually (not
always) the president of PR.