rails-devel — List for discussion of Rails development

Re: [Rails-devel] Report window as game history

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

Very nice.

This may actually help implementing an idea I have lingering in the back of
my head for some time: to have Undo clean up the (editable) report, rather
than just add the unhelpful 'Undo' line. Perhaps, while you're at it...

Erik

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Wednesday 11 August 2010 01:20
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Report window as game history

The linked movesets in the CGR 1856 merger inspired a feature that proved to

be surprisingly easy (as it leverages on the excellent move/state mechanisms

in Rails). The downside is that it can be effected by the all undo related 
bugs, but the number of those was on the decrease lately.

The report window now acts as game history: There are hyperlinks for each 
action. Clicking on any of those lets Rails jump to that game situation (by 
calling undo repeatedly). Return to a later position is possible unless an 
action is taken (as it is the case for standard redo). I also added two 
buttons (<< and >>) to allow single-step moves.

The old report window (which is editable) can be activated via the 
Configuration menu (or setting report.window.type to static in the legacy 
configfiles). 

Stefan

----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Report window as game history

[Chris S. <chr...@gm...>]

Is it still possible to copy text from the Report window for pasting into an
email?

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> wrote:

> The linked movesets in the CGR 1856 merger inspired a feature that proved
> to
> be surprisingly easy (as it leverages on the excellent move/state
> mechanisms
> in Rails). The downside is that it can be effected by the all undo related
> bugs, but the number of those was on the decrease lately.
>
> The report window now acts as game history: There are hyperlinks for each
> action. Clicking on any of those lets Rails jump to that game situation (by
> calling undo repeatedly). Return to a later position is possible unless an
> action is taken (as it is the case for standard redo). I also added two
> buttons (<< and >>) to allow single-step moves.
>
> The old report window (which is editable) can be activated via the
> Configuration menu (or setting report.window.type to static in the legacy
> configfiles).
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Report window as game history

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

The linked movesets in the CGR 1856 merger inspired a feature that proved to 
be surprisingly easy (as it leverages on the excellent move/state mechanisms 
in Rails). The downside is that it can be effected by the all undo related 
bugs, but the number of those was on the decrease lately.

The report window now acts as game history: There are hyperlinks for each 
action. Clicking on any of those lets Rails jump to that game situation (by 
calling undo repeatedly). Return to a later position is possible unless an 
action is taken (as it is the case for standard redo). I also added two 
buttons (<< and >>) to allow single-step moves.

The old report window (which is editable) can be activated via the 
Configuration menu (or setting report.window.type to static in the legacy 
configfiles). 

Stefan

Re: [Rails-devel] Fixes

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

I've got some vague attempts at making 1825 working in my local files.
 You can run the initial distribution and the stock round starts off
but it's far from operational yet (I'm slow and learning as I go :p)

I didn't realise what you told me before when it was added into the
gameslist...It's probably worth taking it out of the list for the time
being since the only operational bit is the map itself and I (and
anyone else who wants to work on it) can just use their own gameslist.

Phil

On 10 August 2010 20:48, Erik Vos <eri...@xs...> wrote:
> I have closed some open bug reports.
>
> 1835 allowed selling shares of unfloated companies and of those floated in
> the current SR. As the rules in fact can be interpreted as forbidding such
> sales if the company has not yet operated, I have used this existing
> configuration item rather than creating a new one. As the PR is exempt to
> the second part of this rule, I am now setting its 'operated' flag
> immediately after formation.
>
> I have also reclassified 1825 from "Experimental" to "Not yet playable" as I
> found a bug report that none of the 1825-specific features did work. That's
> true, because no effort has been put into that task yet, which means that
> the default rules (1830) apply. Apparently the old classification was too
> inviting to try it out.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Fixes

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

I have closed some open bug reports.

1835 allowed selling shares of unfloated companies and of those floated in
the current SR. As the rules in fact can be interpreted as forbidding such
sales if the company has not yet operated, I have used this existing
configuration item rather than creating a new one. As the PR is exempt to
the second part of this rule, I am now setting its 'operated' flag
immediately after formation.

I have also reclassified 1825 from "Experimental" to "Not yet playable" as I
found a bug report that none of the 1825-specific features did work. That's
true, because no effort has been put into that task yet, which means that
the default rules (1830) apply. Apparently the old classification was too
inviting to try it out.

Erik.

[Rails-devel] 1835 company name changes

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

Now that we are in JDG-pleasing mode, I thought I could as well have a look
at his (and other people's) long-standing request to use the "proper" (i.e.
2-letter capital) 1835 major company names. 

Now changing names is trivial, but at the same time keeping backwards
compatibility with respect to saved files is not. That's why it took so long
- I needed a good idea to make that work. The solution is generic: any
(public) company can now have an "alias" name. This alias is (only!) used to
translate old to new names when loading saved files. (New saved files should
only contain the new names - but I haven't checked that yet).

I think it all works now; at least my longish old 1835 saved files still
load. That's no guarantee that I have covered everything, so I would
encourage everyone who's able to run from the newest code to check any 1835
saved files.

Erik.

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

Stefan Frey wrote:
> Some comments and details of the changes below.

> Aliza Panitz wrote:
>> The attached savefile is from a test game with 3 bugs, probably all
>> related to undo actions:
>>
>> (1)  When I undo a tile lay and do something else, the route is not
>> recalculated.  If I don't pay attention and calculate manually, I get
>> the run from the previous OR.

> I could not recreate this behavior exactly, but I found something similar:
> If a company has two base tokens, one with a valid route and another without a 
> valid route, the revenue calculation did

I assume you intended to write "not"...

> return a result. This is the case for 
> the CPR with a lone token in Kitchener. 
> 
> This potentially also explains the complains of John David Galt on the revenue 
> calculation not working in his test of 1835 for BY: I do not have his save 
> file, but I guess that he tokened in Nuernberg and created a similar scenario 
> there. 

BY tokened in Furth and did all subsequent building from there.  Munich had
a token and a tile (since I wasn't allowed to build out of Furth until the
second OR) but not a run.

> Quote from his mail from 06/13/10:
>> "The route calculation logic seems correct when it gives an answer at all.
>> But in most turns it did not even guess at a revenue number for By."

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGR formation hangs game

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

The mail and the save file below contained a plethora of valuable scenarios
to find various bugs. All of them should be fixed in development now, thus we 
only have to wait for Brett for an upcoming release.
I thank Aliza for reporting all those issues, this was an invaluable help to 
track them down.

I have attached two save files:
A) 1856-CGR-formation-undo-bug_trim_329.rails
This is the save file which goes back to the root undo problem.
From here the game could be replayed correctly.

B) 1856_replayed_591_before_cgr.rails
This is the save file which I saved before the CGR formation after replaying 
from the save file in A) using the development version. I am quite confident 
that I made no mistake during the replay, but there is no guarantee.
This save file will only work with the upcoming release.

Stefan

Some comments and details of the changes below.

On Sunday 20 June 2010 05:26:12 Aliza Panitz wrote:
> The attached savefile is from a test game with 3 bugs, probably all
> related to undo actions:
>
> (1)  When I undo a tile lay and do something else, the route is not
> recalculated.  If I don't pay attention and calculate manually, I get
> the run from the previous OR.

I could not recreate this behavior exactly, but I found something similar:
If a company has two base tokens, one with a valid route and another without a 
valid route, the revenue calculation did return a result. This is the case for 
the CPR with a lone token in Kitchener. 

This potentially also explains the complains of John David Galt on the revenue 
calculation not working in his test of 1835 for BY: I do not have his save 
file, but I guess that he tokened in Nuernberg and created a similar scenario 
there. 

Quote from his mail from 06/13/10:
"The route calculation logic seems correct when it gives an answer at all.
But in most turns it did not even guess at a revenue number for By."

>
> (2) If I try an undo during CGR formation (Oh wait, I forgot to buy
> the 5-train over...), the game hangs and cannot be continued.
>
> The CGR ended up with 2 5-trains and 4 4-trains.The next company was
> unable to lay a tile. ;-)

Undo of the CGR formation round is a difficult issue, as the implementation of 
the sequence of companies to merge is not adapted for an easy change to state 
variable. I used an easier approach for some progress here: By linking all CGR 
decisions it is possible to undo the whole formation round in one Undo, which 
actual works now ( at least for my test cases).
I added a few fixed to improve the UI behavior after the undo and there was a 
more serious bug, that the train limit of the CGR could be wrong in some 
cases.

>
> (3) The savefile in question, when I reload it, is complaining about
> an illegal stock action in the round before the CGR formed.  Since I
> started the game in Rails 1.3 and played it through without saving
> until the CGR formed, I would expect any illegal stock move to have
> been noticed earlier. ;-)

That was indeed related to a sequence of undo actions and was already fixed by 
Erik a few days ago.

>
>  - Aliza

Re: [Rails-devel] 18EU "Reload failure"

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

IMO there are enough fixes (including some pretty fundamental ones) to make
a new release useful. There are still several outstanding bug reports that I
want to address, but my progress is slow these days, so it doesn't make much
sense to wait until all of that is done.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Tuesday 03 August 2010 19:14
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 18EU "Reload failure"

Good news first: The bug is already fixed in the development version. 
(Again the third token slot in Berlin, which does not exist at the start of 
the game.)

Unfortunately nothing can be done unless waiting for the next release of the

next version of Rails. 

Brings up the question to Erik and Brett:
There are several fixes in development that avoid reload problems, maybe we 
should schedule a release for the near future.
I have one or two minor changes left and there is still the need to add more

localised text for the configuration UI.

Stefan

On Tuesday 03 August 2010 08:23:43 Spencer Hamblen wrote:
> I'm running into an error with 18EU which seems to be occurring in the
> Final Minor Exchange Round
>
> The first file
> 18EU_20100730_0216_FER_Jay1.rails
> loads normally, but the next (in the stock round following the FMER)
> 18EU_20100730_1521_SR3_2.rails
> gives the error "Load failed, reason: Reload failure" when I try to
> load it.  Any idea what can be done?
>
> -Spencer Hamblen



----------------------------------------------------------------------------
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU "Reload failure"

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

Good news first: The bug is already fixed in the development version. 
(Again the third token slot in Berlin, which does not exist at the start of 
the game.)

Unfortunately nothing can be done unless waiting for the next release of the 
next version of Rails. 

Brings up the question to Erik and Brett:
There are several fixes in development that avoid reload problems, maybe we 
should schedule a release for the near future.
I have one or two minor changes left and there is still the need to add more 
localised text for the configuration UI.

Stefan

On Tuesday 03 August 2010 08:23:43 Spencer Hamblen wrote:
> I'm running into an error with 18EU which seems to be occurring in the
> Final Minor Exchange Round
>
> The first file
> 18EU_20100730_0216_FER_Jay1.rails
> loads normally, but the next (in the stock round following the FMER)
> 18EU_20100730_1521_SR3_2.rails
> gives the error "Load failed, reason: Reload failure" when I try to
> load it.  Any idea what can be done?
>
> -Spencer Hamblen

[Rails-devel] 18EU "Reload failure"

[Spencer H. <pl...@gm...>]

I'm running into an error with 18EU which seems to be occurring in the
Final Minor Exchange Round

The first file
18EU_20100730_0216_FER_Jay1.rails
loads normally, but the next (in the stock round following the FMER)
18EU_20100730_1521_SR3_2.rails
gives the error "Load failed, reason: Reload failure" when I try to
load it.  Any idea what can be done?

-Spencer Hamblen

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

Erik Vos wrote:
> For now it's all or nothing, I'm afraid. I don't remember who asked for it
> (I thought it was you), but at least some people argued that decreasing
> prices should be the normal state of affairs - which I didn't agree with,
> but it was an easy option to add.
> 
> What you really want, it seems, is that on a second sale action, in the same
> turn and for the same company, there should be an option to sell at either
> the original or the new (lower) price. I think that's doable, but not
> trivial, and moreover that additional option should be offered in an
> unintrusive way - I wonder if it's really worth the effort.

I would just put it on the Special menu as a mode you can toggle on/off.

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

For now it's all or nothing, I'm afraid. I don't remember who asked for it
(I thought it was you), but at least some people argued that decreasing
prices should be the normal state of affairs - which I didn't agree with,
but it was an easy option to add.

What you really want, it seems, is that on a second sale action, in the same
turn and for the same company, there should be an option to sell at either
the original or the new (lower) price. I think that's doable, but not
trivial, and moreover that additional option should be offered in an
unintrusive way - I wonder if it's really worth the effort.

Erik.

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Sunday 01 August 2010 19:16
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1851 - Operating Company can't sell a
sharetwicein one turn

Erik Vos wrote:
> I have added a new game option that influences the prices for subsequent
> sell actions of the same company in one turn.
> The default remains, that the price stays the same. This behaviour can now
> be disabled, so that subsequent sell actions are executed at decreasing
> prices. 
> 
> It now works for 1830 only. Some more work on the code is needed to add
> other games. I will do that if we agree that this is the way to go.

I hope this option can be enabled on a per-use basis, not just at start of
game, since it is something a player will only rarely want to do (I can't
think of any use for it except to set up an intentional bankruptcy).

As for other games, I assume most games will not allow it, but 18AL/18GA
should.

----------------------------------------------------------------------------
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

Erik Vos wrote:
> I have added a new game option that influences the prices for subsequent
> sell actions of the same company in one turn.
> The default remains, that the price stays the same. This behaviour can now
> be disabled, so that subsequent sell actions are executed at decreasing
> prices. 
> 
> It now works for 1830 only. Some more work on the code is needed to add
> other games. I will do that if we agree that this is the way to go.

I hope this option can be enabled on a per-use basis, not just at start of
game, since it is something a player will only rarely want to do (I can't
think of any use for it except to set up an intentional bankruptcy).

As for other games, I assume most games will not allow it, but 18AL/18GA
should.

[Rails-devel] New Rails user configuration and settings

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

Over the last few weeks I added a new system to define the Rails user 
configurations, which replaces the old configuration files ("my.properties" 
and user-defined variants).

USER INFORMATION:

* The basic idea is that a collection of user defined settings is a user 
profile and can be saved as a configuration file. Each user profile depends 
on a system profile, which defines default settings.

Currently there is only one pre-defined system profile (called default), but 
this allows pre-defined settings for pbem, ftf or online playing later on.

* There is a prototype for a UI under Options => Configuration which allows to 
change the configurations.

It consists of two panels: The upper part allows to select a profile, create a 
new or load a saved profile.

The second panel allows changes of the various options, which are collected by 
the different panes. 

The bottom row provides buttons to store and apply the new settings or cancel 
the changes.


DEVELOPER INFORMATION:

* The composition of the UI is adjustable by changing the data/Properties.xml.

The section tags refer to the tabbed panes and the property tags to the 
options. The property names are the same as in the old configuration files.
The property type attribute defines the UI element used and should be self 
explaining.

* LocalisedText settings

The text for sections (pane) and properties can be changed in LocalisedText.
Keys are defined using the following patterns:

Section label:
Config.section.{name of section}
Example: Config.section.UI=Windows/Fonts

Property label:
Config.label.{name of property}
Example: Config.label.locale=Language Setting

Property toolTip:
Config.toolTip.{name of property}
Example: 
Config.toolTip.local.player.name=Player name used as suffix for game save

Property infoText:
Config.infoText.{name of property}
Example:
Config.infoText.locale=<html>te_ST shows local text keys. <br> Requires 
restart.</html> 

* Implementation

UI is in rails.ui.swing.ConfigWindow

Behind the scenes all changes are in rails.util.Config and the properties are 
defined using rails.util.ConfigItem.

* Files used
System profiles are stored in folder data.profiles. 

The list of user profiles is stored in the working directory of Rails in the 
file user.profiles.

User configurations can be stored anywhere in the folder system.

Re: [Rails-devel] 1851 - Operating Company can't sell a sharetwicein one turn

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

I have added a new game option that influences the prices for subsequent
sell actions of the same company in one turn.
The default remains, that the price stays the same. This behaviour can now
be disabled, so that subsequent sell actions are executed at decreasing
prices. 

It now works for 1830 only. Some more work on the code is needed to add
other games. I will do that if we agree that this is the way to go.

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Friday 16 July 2010 22:48
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1851 - Operating Company can't sell a
sharetwicein one turn

On Fri, Jul 16, 2010 at 12:39 PM, Erik Vos <eri...@xs...> wrote:
> In Rails, all sell *actions* of shares of the same company (without
> intervening buy action) constitute one *transaction*, for the purpose of
> price setting and/or price movement.
>
> The one game that necessitates this behaviour is 1835, where most
companies
> have both (non-president) 10% and 20%, or 5% and 10% share certificates.
The
> Rails selling mechanic allows selling only one such share unit type in one
> *action*. So if you want to sell one 5% share and one 10% share of PR at
the
> same price, two actions are required to make one transaction.
>
> That's the main reason behind this behaviour. And yes, it precludes
repeated
> selling in one turn at a lower price after each action, as some people
would
> like to have it. We could add an option that allows this, but that option,
> when selected, would have a probably unwanted side effect on 1835.
>

I would like to see this option exist, but only for games that allow
it. Perhaps a game-specific XML option is the way to go here?

> Erik.

---Brett.

> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 16 July 2010 10:28
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1851 - Operating Company can't sell a share
> twicein one turn
>
> I don't believe there is a general consensus among all players but I
> would like to think that the prevailing opinion is that in games where
> selling a 'block' of shares causes a price drop, you cannot sell 1,
> then sell 1, then sell 1 without passing in between and allowing other
> people to react.  If you specifically want to sell to drop the price
> and are happy to take the hit then you have to sell, let the other
> players have a turn each to react, then sell again.
>
> Now, this refers to stock round actions and 1851 where a company is
> selling/buying is an operating round action.  It's not clear from the
> rules I agree but the way we always play these games face to face is
> that each company gets one 'transaction', that is either sell or buy,
> and if you can do as many certs as you like in that transaction.  We
> mostly apply this to EU.
>
> This is only really an issue when you drop one row per block, that
> doesn't happen in 1851, so despite the fact that the 'correct' way of
> doing it would be to just choose to sell all the shares you want in
> the first transaction, someone could theoretically sell 1, sell 1,
> sell 1 and it won't make any difference to the gamestate than selling
> 3 in one transaction, so in this case it should be allowed (despite
> the fact that the user could just click 'undo' then sell the correct
> number of shares as a faster way of doing it.  I'm just trying to
> think of what makes a more pleasant user experience, they shouldn't
> really be left confused because they didn't spot the dropdown box on
> the sell screen
>
> Phil
>
> On 15 July 2010 22:49, Stefan Frey <ste...@we...> wrote:
>> A current open bug report for 1851:
>>> When I try to sell a second company share during that company's
operating
>>> round, Rails says I can't sell after buying. This appears to be
>>> inconsistent with the rules.
>> refers to the fact that it is not possible to sell other shares from the
>> Treasury after a first sell transaction (and the error message is
> confusing).
>>
>> Question is, similar to the discussion we had previously on selling in
>> separate transactions but same player turn in 1835, 1830 and 1870:
>>
>> Should the second transaction use the initial price at the start of the
>> players turn (thus identical to the one used for the first transaction)
or
>> the reduced price taking the the stock market reaction into account?
>>
>> I have not found a ruling in 1851, thus I am inclined to follow the
> current
>> standard implementation in Rails (identical to the first transaction),
>> however - if I remember correctly - there was no general consensus for
> this
>> (at least for 1830).
>>
>> Stefan
>>
>>
>
----------------------------------------------------------------------------
> --
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
----------------------------------------------------------------------------
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

This was after all sorts of whacky other issues and a game played on
workarounds so It's entirely likely something went weird...I'll try
and dig out my game log and play this through on current devcode, see
where we get to.

Phil

On 28 July 2010 22:06, Erik Vos <eri...@xs...> wrote:
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 17 June 2010 13:15
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds
>
> 1. the privates close on the sale of the first 5 but any PrePrussian
> privates stay in players hands and you are no longer prompted to
> convert them at the start of future rounds (the HB in my case)
>
> [EV] Phil, I cannot reproduce this with the current code. I tried a case
> where only the M2 converted when the 4+4 was bought.
> Later in that same OR the 5T was bought and all Preprussians converted. Same
> thing if the 5T was bought in the next OR.
> So I'm not sure what went wrong in your case.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 17 June 2010 13:15
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds

1. the privates close on the sale of the first 5 but any PrePrussian
privates stay in players hands and you are no longer prompted to
convert them at the start of future rounds (the HB in my case)

[EV] Phil, I cannot reproduce this with the current code. I tried a case
where only the M2 converted when the 4+4 was bought.
Later in that same OR the 5T was bought and all Preprussians converted. Same
thing if the 5T was bought in the next OR.
So I'm not sure what went wrong in your case.

Erik.

[Rails-devel] Reload problems

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

I have modified another basic process that has (rightly) been frowned upon
recently as a possible cause of bugs. 

Executed actions are no longer saved as a List<PossibleAction> but as a
containerless sequence of PossibleAction objects.
This allows postponing object assignment during deserialization until all
previous actions have been processed, so that at the game always is in the
same state as during playing the game. 
This should fix (or at least help fixing) saved file loading problems that
are attributable to assignment to objects that do not exist at the start of
the game.

Erik.

Re: [Rails-devel] Bug: 18EU issue with starting a new minor afterphase 5

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

Erik:
you are right: the non-synchronous behavior of the deserialization and the 
game progress is the deeper cause for those issues.

I agree that not-storing the actions as a list, but separately inside the save 
file, makes sense. There are two other reasons for that:

* It would simplify the creation as the autosave file, as currently I create a 
new complete save file and overwrite the old one. Simply appending the 
additional action is easier.

* I experimented a little bit to synchronize two Rails instances to find out 
how difficult it is to add network play. For this I think the easiest way is 
to share the actions between the instances. Storing the actions separately, 
would make reloading a game or receiving actions over the network nearly 
identical.
I have to admit, that the experience from the experiment was mixed: The good 
thing is that it in principle it does work, but there is still a lot of work 
required (some parts of the actions code does not work, and there are several 
glitches on the UI, especially for tile laying).

All in all I think this is a good idea.

Stefan

On Saturday 24 July 2010 11:36:31 Erik Vos wrote:
> If I understand all of this correctly, the issue is that all saved actions
> are all deserialized before even one is processed.
>
> Once I realized (a bit late) that this is the heart of the problem, I
> remembered a past discussion where we concluded that it is unfortunate that
> the actions are saved as members of a List, rather than individually.
> (Perhaps for a different reason, but I don't remember what started that
> discussion.)
>
> Well, perhaps it is now time to do something about it. On saving, it's
> trivial to remove the List container, and on reloading, a little
> refactoring would be needed, but it's not complicated at all (including
> keeping backwards compatibility). Once done, each action should be
> deserialized against the current state of the game as it was at original
> execution time.
>
> This approach looks simpler and less intrusive to me that the split
> proposed below.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 23 July 2010 12:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug: 18EU issue with starting a new minor
> afterphase 5
>
> Stefan,
>
> Excellent, thanks for looking into that.  Could LayBaseTokens have an
> issue in 1856 where you could lay a token on a station that was a dot
> town rather than a city at the beginning of the game?  I'd guess not
> from what you say above.  Further to that...is it sensible to
> initialize everything on first access rather than at deserialization?
> Then in theory the save file is always replaying things at the state
> they were during original gameplay?
>
> Phil
>
> On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> > Phil:
> > the problem is fixed now in SVN.
> > Your file did not work on the current development version, as there is a
> > change already, which excludes non-active players from the auction.
> > I removed the additional pass of your save file (see attachment).
> > It should now work under development at least.
> > For 1.3 there is no fix possible.
> > Stefan
> >
> > Details of the problem:
> >
> > The bug is similar to the reload bug of the infinite last train:
> > The token was laid in a station in Berlin, which did not exist at the
>
> start of
>
> > the game and thus the action was not intialized correctly.
> >
> > This brings up another general rule for the reload mechanism:
> > Items, which do not exist at the beginning of the game, should not be
> > intialized at the deserialization (readObject), but at the time of the
>
> first
>
> > access. (This mechanism was introduced by Erik in buyTrain).
> >
> > I know wonder, which elements of Rails might not be created from the
>
> beginning
>
> > and which actions might be effected. I looked into some potential
>
> candidates,
>
> > but there might be still some other.
> >
> > Known objects with potential problems:
> > * City (stations which are not available at the start of the game)
> > * Train (available at infinite quantities)
> >
> > Known objects without problems:
> > * Tile (only one tile created, regardless of quantity)
> > * BonusTokens (only one token created per token class, regardless of
>
> quantity)
>
> > Effected classes:
> > City:
> > * LayBaseTokens: No problem, stations are reference by integer ids only
> > * StartCompany: Fixed now
> > * LayTile: No problem, relaidbasetokens is coded by a String, which is
>
> parsed
>
> > after access only
> >
> > Train:
> > * Buy Train (the train bought is fixed, but the exchange train could be
> > effected)
> > * Discard Train (the discarded train could be effected)
> > -> Both cases are currently unlikely, as the train category with infinite
> > supply is usually the best, but this might change in the future,
>
> especially
>
> > trains not triggering phase changes might be in infinite supply
> >
> > On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
> >> Save file 18EU_20100720_1336_Chris.rails
> >>
> >> Load up and start KBS at 100, base city Berlin.  Processes this action
> >> totally fine.
> >>
> >> Now save the game, and reload it (or just load
> >> 18EU_20100720_1602_Bug.rails).  Load error.
> >>
> >> I traced the execution of the startCompany action and it gets
> >> processed and logged with the correct selectedHomeCity. The
> >> selectedHomeCity gets written to the executedActions log happily as
> >> well.  Yet for some reason when you reload the game, the
> >> selectedHomeCity object for that action is a null value.  It looks
> >> like the ObjectOutputStream is, for some reason, failing to write the
> >> selectedHomeCity object to the save file, causing the reload to fail.
> >>
> >> Any thoughts??
> >>
> >> You will have to load this on 1.3 by the way, I can't load this file
> >> at all against the current head revision of the code.
> >>
> >> Phil
>
> ---------------------------------------------------------------------------
>- --
>
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Bug: 18EU issue with starting a new minor afterphase 5

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

If I understand all of this correctly, the issue is that all saved actions
are all deserialized before even one is processed. 

Once I realized (a bit late) that this is the heart of the problem, I
remembered a past discussion where we concluded that it is unfortunate that
the actions are saved as members of a List, rather than individually.
(Perhaps for a different reason, but I don't remember what started that
discussion.) 

Well, perhaps it is now time to do something about it. On saving, it's
trivial to remove the List container, and on reloading, a little refactoring
would be needed, but it's not complicated at all (including keeping
backwards compatibility). Once done, each action should be deserialized
against the current state of the game as it was at original execution time.

This approach looks simpler and less intrusive to me that the split proposed
below.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 23 July 2010 12:06
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Bug: 18EU issue with starting a new minor
afterphase 5

Stefan,

Excellent, thanks for looking into that.  Could LayBaseTokens have an
issue in 1856 where you could lay a token on a station that was a dot
town rather than a city at the beginning of the game?  I'd guess not
from what you say above.  Further to that...is it sensible to
initialize everything on first access rather than at deserialization?
Then in theory the save file is always replaying things at the state
they were during original gameplay?

Phil

On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> Phil:
> the problem is fixed now in SVN.
> Your file did not work on the current development version, as there is a
> change already, which excludes non-active players from the auction.
> I removed the additional pass of your save file (see attachment).
> It should now work under development at least.
> For 1.3 there is no fix possible.
> Stefan
>
> Details of the problem:
>
> The bug is similar to the reload bug of the infinite last train:
> The token was laid in a station in Berlin, which did not exist at the
start of
> the game and thus the action was not intialized correctly.
>
> This brings up another general rule for the reload mechanism:
> Items, which do not exist at the beginning of the game, should not be
> intialized at the deserialization (readObject), but at the time of the
first
> access. (This mechanism was introduced by Erik in buyTrain).
>
> I know wonder, which elements of Rails might not be created from the
beginning
> and which actions might be effected. I looked into some potential
candidates,
> but there might be still some other.
>
> Known objects with potential problems:
> * City (stations which are not available at the start of the game)
> * Train (available at infinite quantities)
>
> Known objects without problems:
> * Tile (only one tile created, regardless of quantity)
> * BonusTokens (only one token created per token class, regardless of
quantity)
>
> Effected classes:
> City:
> * LayBaseTokens: No problem, stations are reference by integer ids only
> * StartCompany: Fixed now
> * LayTile: No problem, relaidbasetokens is coded by a String, which is
parsed
> after access only
>
> Train:
> * Buy Train (the train bought is fixed, but the exchange train could be
> effected)
> * Discard Train (the discarded train could be effected)
> -> Both cases are currently unlikely, as the train category with infinite
> supply is usually the best, but this might change in the future,
especially
> trains not triggering phase changes might be in infinite supply
>
>
> On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
>> Save file 18EU_20100720_1336_Chris.rails
>>
>> Load up and start KBS at 100, base city Berlin.  Processes this action
>> totally fine.
>>
>> Now save the game, and reload it (or just load
>> 18EU_20100720_1602_Bug.rails).  Load error.
>>
>> I traced the execution of the startCompany action and it gets
>> processed and logged with the correct selectedHomeCity. The
>> selectedHomeCity gets written to the executedActions log happily as
>> well.  Yet for some reason when you reload the game, the
>> selectedHomeCity object for that action is a null value.  It looks
>> like the ObjectOutputStream is, for some reason, failing to write the
>> selectedHomeCity object to the save file, causing the reload to fail.
>>
>> Any thoughts??
>>
>> You will have to load this on 1.3 by the way, I can't load this file
>> at all against the current head revision of the code.
>>
>> Phil
>
>
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

Fixed this one (was just a configuration error).
Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 17 June 2010 13:15
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835: Later Prussian formation rounds

2. during phase '5' (the 5 train just bought, just to be clear) the
Prussian has a train limit of 2, not 3

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformationhangs game

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

OK, I have bitten the bullet and changed BuyCertificate to use company name
and share size in stead of certificate ID, while maintaining backwards
compatibility. I have tested against various late-game test cases of all
major playable games, and it seems all right now. It would be good if anyone
able to run from the latest code could run their own cases against it.

I did not do much checking of Undo/Redo, except for the specific 1889 case
that started it all. Undo is still known to be imperfect in some cases, and
can better be avoided; it's always safer to restart from a saved game.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Sunday 18 July 2010 22:39
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
duringCGRformationhangs game

Yes, I agree that finding the seller is the catch.
MoveableHolder requires all portfolios (potential sellers) to have a name,
so perhaps what we need is a Map to link names to portfolios.

Thinking about it: identifying the seller and the share type bought is only
role currently fulfilled by passing the cert (ID), because after extracting
that info the cert ID itself is ignored. So why not pass seller name and
share type explicitly? Detecting the wrong seller is exactly the problem we
face.

One other issue then is to make the old and new version of BuyCertificate
compatible for deserialization, because I would hate to invalidate all my
test cases. But that should be doable.

Erik.

Re: [Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Stefan,

Excellent, thanks for looking into that.  Could LayBaseTokens have an
issue in 1856 where you could lay a token on a station that was a dot
town rather than a city at the beginning of the game?  I'd guess not
from what you say above.  Further to that...is it sensible to
initialize everything on first access rather than at deserialization?
Then in theory the save file is always replaying things at the state
they were during original gameplay?

Phil

On 21 July 2010 20:24, Stefan Frey <ste...@we...> wrote:
> Phil:
> the problem is fixed now in SVN.
> Your file did not work on the current development version, as there is a
> change already, which excludes non-active players from the auction.
> I removed the additional pass of your save file (see attachment).
> It should now work under development at least.
> For 1.3 there is no fix possible.
> Stefan
>
> Details of the problem:
>
> The bug is similar to the reload bug of the infinite last train:
> The token was laid in a station in Berlin, which did not exist at the start of
> the game and thus the action was not intialized correctly.
>
> This brings up another general rule for the reload mechanism:
> Items, which do not exist at the beginning of the game, should not be
> intialized at the deserialization (readObject), but at the time of the first
> access. (This mechanism was introduced by Erik in buyTrain).
>
> I know wonder, which elements of Rails might not be created from the beginning
> and which actions might be effected. I looked into some potential candidates,
> but there might be still some other.
>
> Known objects with potential problems:
> * City (stations which are not available at the start of the game)
> * Train (available at infinite quantities)
>
> Known objects without problems:
> * Tile (only one tile created, regardless of quantity)
> * BonusTokens (only one token created per token class, regardless of quantity)
>
> Effected classes:
> City:
> * LayBaseTokens: No problem, stations are reference by integer ids only
> * StartCompany: Fixed now
> * LayTile: No problem, relaidbasetokens is coded by a String, which is parsed
> after access only
>
> Train:
> * Buy Train (the train bought is fixed, but the exchange train could be
> effected)
> * Discard Train (the discarded train could be effected)
> -> Both cases are currently unlikely, as the train category with infinite
> supply is usually the best, but this might change in the future, especially
> trains not triggering phase changes might be in infinite supply
>
>
> On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
>> Save file 18EU_20100720_1336_Chris.rails
>>
>> Load up and start KBS at 100, base city Berlin.  Processes this action
>> totally fine.
>>
>> Now save the game, and reload it (or just load
>> 18EU_20100720_1602_Bug.rails).  Load error.
>>
>> I traced the execution of the startCompany action and it gets
>> processed and logged with the correct selectedHomeCity. The
>> selectedHomeCity gets written to the executedActions log happily as
>> well.  Yet for some reason when you reload the game, the
>> selectedHomeCity object for that action is a null value.  It looks
>> like the ObjectOutputStream is, for some reason, failing to write the
>> selectedHomeCity object to the save file, causing the reload to fail.
>>
>> Any thoughts??
>>
>> You will have to load this on 1.3 by the way, I can't load this file
>> at all against the current head revision of the code.
>>
>> Phil
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Bug: 18EU issue with starting a new minor after phase 5

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

Phil:
the problem is fixed now in SVN.
Your file did not work on the current development version, as there is a 
change already, which excludes non-active players from the auction.
I removed the additional pass of your save file (see attachment).
It should now work under development at least.
For 1.3 there is no fix possible.
Stefan

Details of the problem:

The bug is similar to the reload bug of the infinite last train:
The token was laid in a station in Berlin, which did not exist at the start of 
the game and thus the action was not intialized correctly.

This brings up another general rule for the reload mechanism:
Items, which do not exist at the beginning of the game, should not be 
intialized at the deserialization (readObject), but at the time of the first 
access. (This mechanism was introduced by Erik in buyTrain). 

I know wonder, which elements of Rails might not be created from the beginning 
and which actions might be effected. I looked into some potential candidates, 
but there might be still some other.

Known objects with potential problems:
* City (stations which are not available at the start of the game)
* Train (available at infinite quantities)

Known objects without problems:
* Tile (only one tile created, regardless of quantity)
* BonusTokens (only one token created per token class, regardless of quantity)

Effected classes:
City:
* LayBaseTokens: No problem, stations are reference by integer ids only
* StartCompany: Fixed now
* LayTile: No problem, relaidbasetokens is coded by a String, which is parsed 
after access only

Train:
* Buy Train (the train bought is fixed, but the exchange train could be 
effected)
* Discard Train (the discarded train could be effected)
-> Both cases are currently unlikely, as the train category with infinite 
supply is usually the best, but this might change in the future, especially 
trains not triggering phase changes might be in infinite supply


On Tuesday 20 July 2010 18:39:11 Phil Davies wrote:
> Save file 18EU_20100720_1336_Chris.rails
>
> Load up and start KBS at 100, base city Berlin.  Processes this action
> totally fine.
>
> Now save the game, and reload it (or just load
> 18EU_20100720_1602_Bug.rails).  Load error.
>
> I traced the execution of the startCompany action and it gets
> processed and logged with the correct selectedHomeCity. The
> selectedHomeCity gets written to the executedActions log happily as
> well.  Yet for some reason when you reload the game, the
> selectedHomeCity object for that action is a null value.  It looks
> like the ObjectOutputStream is, for some reason, failing to write the
> selectedHomeCity object to the save file, causing the reload to fail.
>
> Any thoughts??
>
> You will have to load this on 1.3 by the way, I can't load this file
> at all against the current head revision of the code.
>
> Phil