rails-devel — List for discussion of Rails development

Re: [Rails-devel] Test report: 1835 in Rails 1.5.1

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

This is a  follow-up to the one of the issues in the 1835 test report:

I think we should highlight somewhere in the wiki and the comments for the 
restrictions that the tile and token laying rule enforcement and highlighting 
currently suggest and allows some illegal tile and token lays. However both 
mechanisms should NEVER disallow or forget to suggest allowed and illegal tile 
lays. The latter are always bugs and should be reported. The other round is 
currently unavoidable and have to be handled by the players themselves.

I quickly went through the 1835 game file and I have not found a situation 
where the tile/token highlighting forgot to suggest a valid hex, but it is 
easy to make a mistake here.

So if John or Erik could possible point out some cases the algorithm missed 
upgradable or buildable hexes in that test game, that would be helpful.

Stefan


Some longer remarks on the token and tile laying logic:

There are currently several parts of code that try to add some help for tile 
and token laying. However they are independent from each other and focus on 
different aspects.

A) The main rails game engine suggests Tile and Token laying actions are based 
only on the knowledge of available token and tile laying actions of the 
company.  It currently has knowledge of the map configuration, availability of 
tiles and/or the network of the operating company.
After a tile lay or token lay it checks if the company has sufficient funds 
available to execute the action.

B) There is some support code in the Rails GUI to guide the user through the 
tile selection process. However it can only considers the selected hex and its 
local neighborhood, but has no knowledge about the network of the operating 
company and/or if the company has sufficient funding to execute this action.

C) The highlighting of suggested hexes for tile and token lay is then again 
simply based on the operating companies network only: It highlights all hexes 
that are reachable by the current network and it checks if there is any tile 
that is in the upgrade path of the current tile. It however does not take into 
account the specific neighborhood of the current hex and/or if the company has 
the required funding to executed such an action.

A perfect solution would merge all those checks into one. However this is not 
so easy as it might seem in first place. On a second look it is a non-trivial 
task to find out if and where are valid tile lays considering all constraints 
(operating company network, operating company funding, tile upgrade charts, 
tile availability, local neighborhood restrictions for tile upgrades, checking 
for the permissive or (semi-)restrictive upgrade rules etc.).

> 
> > 9. The Pfalzbahnen owner is being offered opportunities to lay a token
> 
> using
> 
> > its special power even when impossible (because the company currently
> > operating has run out of tokens and/or already has one in the Pfalz hex).
> 
> Yes, that's a detail that still needs to be addressed.  I have no solution
> for that yet. See also your next point.
> 
> > 10. The Map window now allows a "Special" action to close private
> 
> companies
> 
> > voluntarily.  I don't think this is legal in 1835.  (I ran across this
> 
> while looking
> 
> > for a command to use Pfalz's power to lay a tile.  I think this "Special"
> 
> menu
> 
> > would be a much better place for tile- and token-laying powers to be,
> 
> rather
> 
> > than make the user click "No Tile" or "No Token" an extra time every
> > turn. But I suppose that's a style issue.)
> 
> This is a stop-gap to enable closing privates that do not automatically
> close according to the rules, such as the PfB above. This also applies to
> the OBB.
> Once all that works correctly, this option will be removed.
> 
> > 11. The tile-laying logic is mostly correct but still suggests tile lays
> 
> where the
> 
> > new tile is rotated in a way that makes it not connect to any station of
> 
> the
> 
> > company.  And there are situations where some tile lays are allowed but
> > nothing gets suggested.
> 
> Indeed the tile laying process needs several refinements.  We all know, and
> if it was easy it would probably have been done already.
> 
> > (This game, the Pfalz owner did not have a major company before Phase 3,
> > so I was unable to verify whether it still offers the Pfalz tile-lay on
> 
> every
> 
> > major-company turn of that player during yellow phase, which should never
> > happen because the tile lay is impossible then.)
> > 
> > 12. The token-laying logic similarly still makes mistakes.  It suggests
> 
> every turn
> 
> > that BY lay a station marker in the south side of Nurnberg- Furth, even
> > though it laid one on the north side in OR2 using the NF.
> 
> That would obviously be a bug.
> 
> > (Oddly enough, in a problem that resembles point 3 in reverse, the five
> > PR tokens that are supposed to be reserved for exchanging minor company
> > tokens
> > *do* show up as available to be built.  Next time I'll try to build them
> 
> in
> 
> > arbitrary locations and see what happens -- both then and when the minor
> > companies merge and there aren't any PR tokens for them.)
> 
> Interesting question: are these PR tokens really reserved?  I don't believe
> the rules say so.
> 

Re: [Rails-devel] Java webstart (was: Rails 1.5.1 available)

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

Okay. Sounds like a fair bit of work to do, but very worthwhile. :-)

---Brett.



On Wed, Oct 19, 2011 at 11:31 AM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I had a first look into adding Java Webstart support for Rails and as
> suspected there is an issue with the Classloader. Even if we provide a user
> defined classloader it is not used in those cases where Rails uses the
> Class.forName method to create new (18xx-game specific classes). This has to
> replaced.
>
> Reference:
> http://download.oracle.com/javase/1,5.0/docs/guide/javaws/developersguide/faq.html#211
>
> In addition we have to make sure that all other resource files also get loaded
> by the classloader from the jar.
>
> Except from that it is mainly an issue to write the ant-tasks for packaging a
> jar for Rails only and then upload this and the library jars (after signing
> them) to sourceforge. This can heavily automated by creating an ant task.
>
> As it still requires some code/build modifications I prefer to add that to the
> to-do list for Rails 2.0 and have no intention to backport this to Rails 1.x.
>
> Stefan
>
>
> On Monday, October 10, 2011 09:02:04 pm brett lentz wrote:
>> I suspect it was my own lack of knowledge on the whole process.
>>
>> Our classloader (and hex drawing code) comes from the Colossus project
>> ( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
>> doubt there's any technical blockers to providing one.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
>> > Do you remember what the main obstacle was? I suspect the
>> > custom made classloader?
>> >
>> > On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
>> >> I looked at creating a JNLP several years ago, but couldn't really
>> >> make heads or tails of the process.
>> >>
>> >> If you can make it happen, that'd be awesome. I'd love to have a link
>> >> on the website that people can click on to launch the latest version
>> >> of Rails.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
>> >> > Erik:
>> >> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
>> >> >
>> >> > I was thinking about that too, as changing the version number is the
>> >> > only remaining manual task to publish a new release.
>> >> >
>> >> > However there will always the need to update the wiki and html pages,
>> >> > so it still requires manually intervention.
>> >> >
>> >> > I am considering adding webstart support (in addition to the file
>> >> > releases - not as an replacement), but I want like to know the
>> >> > opinions of the others about that?
>> >> >
>> >> > Stefan
>> >> >
>> >> >> I have no opinion on whether or not to put branches in the repo, as I
>> >> >> ignore them all (so far). However, I would like to see a correct (if
>> >> >> temporary) version number in the master Game.xml, so that the
>> >> >> approximate version of saved files can be identified. In my opinion
>> >> >> that should be 1.5.1+, literally: 1.5.1 and more.
>> >> >> (A build number would be even better, once we have managed nightly or
>> >> >> weekly builds. Would it be possible to have the code retrieve the
>> >> >> latest commit hash?)
>> >> >>
>> >> >> Erik.
>> >> >>
>> >> >>
>> >> >>

Re: [Rails-devel] Java webstart (was: Rails 1.5.1 available)

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

Brett:
I had a first look into adding Java Webstart support for Rails and as 
suspected there is an issue with the Classloader. Even if we provide a user 
defined classloader it is not used in those cases where Rails uses the 
Class.forName method to create new (18xx-game specific classes). This has to 
replaced.

Reference:
http://download.oracle.com/javase/1,5.0/docs/guide/javaws/developersguide/faq.html#211

In addition we have to make sure that all other resource files also get loaded 
by the classloader from the jar.

Except from that it is mainly an issue to write the ant-tasks for packaging a 
jar for Rails only and then upload this and the library jars (after signing 
them) to sourceforge. This can heavily automated by creating an ant task.

As it still requires some code/build modifications I prefer to add that to the 
to-do list for Rails 2.0 and have no intention to backport this to Rails 1.x.

Stefan


On Monday, October 10, 2011 09:02:04 pm brett lentz wrote:
> I suspect it was my own lack of knowledge on the whole process.
> 
> Our classloader (and hex drawing code) comes from the Colossus project
> ( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
> doubt there's any technical blockers to providing one.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
> > Do you remember what the main obstacle was? I suspect the
> > custom made classloader?
> > 
> > On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
> >> I looked at creating a JNLP several years ago, but couldn't really
> >> make heads or tails of the process.
> >> 
> >> If you can make it happen, that'd be awesome. I'd love to have a link
> >> on the website that people can click on to launch the latest version
> >> of Rails.
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> >> > Erik:
> >> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
> >> > 
> >> > I was thinking about that too, as changing the version number is the
> >> > only remaining manual task to publish a new release.
> >> > 
> >> > However there will always the need to update the wiki and html pages,
> >> > so it still requires manually intervention.
> >> > 
> >> > I am considering adding webstart support (in addition to the file
> >> > releases - not as an replacement), but I want like to know the
> >> > opinions of the others about that?
> >> > 
> >> > Stefan
> >> > 
> >> >> I have no opinion on whether or not to put branches in the repo, as I
> >> >> ignore them all (so far). However, I would like to see a correct (if
> >> >> temporary) version number in the master Game.xml, so that the
> >> >> approximate version of saved files can be identified. In my opinion
> >> >> that should be 1.5.1+, literally: 1.5.1 and more.
> >> >> (A build number would be even better, once we have managed nightly or
> >> >> weekly builds. Would it be possible to have the code retrieve the
> >> >> latest commit hash?)
> >> >> 
> >> >> Erik.
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> --- --- --- All the data continuously generated in your IT
> >> >> infrastructure contains a definitive record of customers,
> >> >> application performance, security threats, fraudulent activity and
> >> >> more. Splunk takes this data and makes sense of it. Business sense.
> >> >> IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> > 
> >> > ----------------------------------------------------------------------
> >> > --- ----- All the data continuously generated in your IT
> >> > infrastructure contains a definitive record of customers, application
> >> > performance, security threats, fraudulent activity and more. Splunk
> >> > takes this data and makes sense of it. Business sense. IT sense.
> >> > Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Another Rails 2.0 code update

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

Stefan,

I noticed from your last commit that you have removed a lot of redundant
interfaces.  That is definitely a big improvement.

I'm not sure if I will have an opportunity to look at your new code very
soon, but in any case it sounds promising.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Friday, October 14, 2011 7:16 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Another Rails 2.0 code update
> 
> All:
> Another milestone is reached: A commit without compile errors was pushed
> to the Rails 2.0 branch. But do expect it to run, that is the next
milestone ;-)
> 
> And most of the redesign of the Model/State concepts is done, but there is
a
> lot of follow-up todos and fixes necessary.
> 
> As the old type of moves mainly effected the ownership of Rails elements
> (like a company owns shares, trains, etc.) I was forced (or had the
> opportunity) to have a closer look onto this area of code and decided to
> change that to some extent too.
> 
> The good thing is that if everything is cleaned up in the end, the change
of
> ownership only requires the issue of object.moveTo(newOwner) and
> everything else is hidden behind the scenes: Setting the new owner inside
> the owner, adding the object to the portfolio and/or holder variable of
the
> new owner and removing from the portfolio of the previous owner.
> 
> Even if this seems like magic, I focused to keep the code simple and to
use
> some generics, but not too much of it, avoiding recursive or multiple
usage of
> it, which can be quite confusing in Java.
> 
> I will soon upload the Javadocs of Rails 2.0 to sourceforge. If anyone is
> interested to have a look now, the interesting changes are all in
> rails.game.model and rails.game.state.
> 
> I hope to get the opportunity soon to write some more about that all, but
> there is always the trade off between writing code and writing about code.
> 
> Anyway this should indicate that there is some serious development going
> forward here and one should keep in mind that it gets more and more
> difficult for me to merge changes in Rails 1.x to Rails 2.0 branch.
> So please avoid major refactoring inside Rails 1.x or be aware that I
might not
> be able to merge it into Rails2.0.
> 
> Stefan
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Another Rails 2.0 code update

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

All:
Another milestone is reached: A commit without compile errors
was pushed to the Rails 2.0 branch. But do expect it to run, that 
is the next milestone ;-)

And most of the redesign of the Model/State concepts is done, but there
is a lot of follow-up todos and fixes necessary.

As the old type of moves mainly effected the ownership of Rails elements (like 
a company owns shares, trains, etc.) I was forced (or had the opportunity) to 
have a closer look onto this area of code and decided to change that to some
extent too.

The good thing is that if everything is cleaned up in the end, the change of 
ownership only requires the issue of object.moveTo(newOwner) and everything 
else is hidden behind the scenes: Setting the new owner inside the owner, 
adding the object to the portfolio and/or holder variable of the new owner and 
removing from the portfolio of the previous owner.

Even if this seems like magic, I focused to keep the code simple and to use 
some generics, but not too much of it, avoiding recursive or multiple usage of 
it, which can be quite confusing in Java.

I will soon upload the Javadocs of Rails 2.0 to sourceforge. If anyone is 
interested to have a look now, the interesting changes are all in 
rails.game.model and rails.game.state.

I hope to get the opportunity soon to write some more about that all, but 
there is always the trade off between writing code and writing about code.

Anyway this should indicate that there is some serious development going 
forward here and one should keep in mind that it gets more and more difficult 
for me to merge changes in Rails 1.x to Rails 2.0 branch.
So please avoid major refactoring inside Rails 1.x or be aware that I might 
not be able to merge it into Rails2.0.

Stefan

Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP) - corrected

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

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]

> 2. During a starting packet purchase round, if a player cannot take any
action
> (has too little money to buy anything currently available) a popup appears
> "[name] cannot buy anything" with an OK button.  If two players are
skipped
> they are combined on one popup.  That's cute, but I'd prefer the turns be
> silently skipped.

I have removed this popup.  The messages are still reported.

> Oddly enough, the stock round behavior is not the same.  If a player
cannot
> take any action on his stock turn (he has too little money to buy anything
> currently available, and owns nothing that can currently be sold) he still
gets a
> turn, even though "Pass" and "Autopass" are the only actions allowed.
> Again, I'd prefer the turn be silently skipped.

I tried, but, as I feared, it can't currently be done in a simple way
without breaking compatibility.
I have added this request to the Wiki list of things to do when we decide to
break compatibility.

I have also moved StartRound_1835 to the 1835-specific code package.
StartRound_1830 stays in the game package because it used by many games.
Perhaps it should be renamed to StartRound_Basic or StartRound_1830Style.

Erik.

Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP) - corrected

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

Found and fixed two 1835 bugs.  Game Notes updated.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]

> 4. The bug reported in Game Notes, where the game would hang if the By
> did not float in the first round, is no longer fatal, at least for me.

Fixed this one, and removed it from the Game Notes. 
The error was that no possible actions were generated in this situation.

> To be exact: As soon as the "Start Round" is passed out, focus moves to
the
> Game Status window, and its "Pass" and "Autopass" buttons change color as
> if they'd been enabled (but that window's name does NOT change to "Stock
> Round [n]", and a popup "Error: No action available" appears).

I found the focus moving to the Map window. 

> I worked around this by simply doing File -> Save on the menu bar and
saving
> the game.  (A restore wasn't needed.)  This moved the focus to the map
> window and made it an operating round, which of course is how it should
> have been.  When the OR finished, "Start Round" reappeared on the screen.

So this workaround is no longer necessary.

> 5. Nit: The first operating round is still "0.1".

No longer (as a side effect of the above fix).

> 14. The game reaches the point of the attached save file.  When the PR
buys
> the 5-train, SX has to discard a train (correctly changed from happening
upon
> purchase of the 4+4).  But then the game hangs while trying to merge the
> remaining private and minor companies.  I had to "undo" the 5-train
purchase
> (using the report window) to be able to save the game.
> 
> I've included the log as well.

A real bug: already closed privates (HB in this case) were again submitted
to the merge step in the PR formation process.
Fixed.

I have also put the correct workaround into the Game Notes for cases where
PfB en OBB do not close where these should: use the Special|Close privates
menu option.

Erik.

Re: [Rails-devel] Phase mgmt step 5: extra tile lays

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

Good to know.  But I do not think that we need a generic provision for these
exceptions.

1880 already has a specific PublicCompany_1880 class, where this special
case can be implemented by overriding getNumberOfTileLays().

1853 is not yet in the picture, but I suppose it can be solved similarly in
that game.

 

Erik.

 

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Thursday, October 13, 2011 1:14 AM
To: Dr....@t-...; Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Phase mgmt step 5: extra tile lays

 

That's 1880.  BCR can lay two yellow from the beginning, other major
companies have to wait for phase 3.

 

And in 1853, companies have to decide if they will lay two yellow from the
start for a fee, or if they will wait until phase 3 to activate the ability,
in which case it is free.


 

--
Chris

Please consider the environment before printing this e-mail.



On Wed, Oct 12, 2011 at 1:39 PM, Dr....@t-...
<Dr....@t-...> wrote:

Hi Erik,

 

i vaguely remember one game where one company has the right to lay 2 yellow
tiles and others are not allowed to do so.

 

1841 .... Major Companies are allowed 2 while minor just one tile...

 

Regards,

Martin


----------------------------------------------------------------------------
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

 

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

On 2011-10-11 05:46, brett lentz wrote:
> I didn't necessarily mean remove the actions from the log or save
> file. I meant simply that we'd silently move the game forward until
> there's an action needing player intervention.

That's what I meant also.  Let the report window (log) continue to report that
"Bill couldn't buy anything."  If the player wonders why his turn was skipped,
he can look there.

Re: [Rails-devel] Phase mgmt step 5: extra tile lays

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

That's 1880.  BCR can lay two yellow from the beginning, other major
companies have to wait for phase 3.

And in 1853, companies have to decide if they will lay two yellow from the
start for a fee, or if they will wait until phase 3 to activate the ability,
in which case it is free.

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Oct 12, 2011 at 1:39 PM, Dr....@t-... <
Dr....@t-...> wrote:

> Hi Erik,
>
>
>
> i vaguely remember one game where one company has the right to lay 2 yellow
> tiles and others are not allowed to do so.
>
>
>
> 1841 .... Major Companies are allowed 2 while minor just one tile...
>
>
>
> Regards,
>
> Martin
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Phase mgmt step 5: extra tile lays

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

Major and minor are company *types*, so no problem here.

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, October 12, 2011 10:40 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Phase mgmt step 5: extra tile lays

 

Hi Erik,

 

i vaguely remember one game where one company has the right to lay 2 yellow tiles and others are not allowed to do so.

 

1841 .... Major Companies are allowed 2 while minor just one tile...

 

Regards,

Martin

Re: [Rails-devel] Phase mgmt step 5: extra tile lays

[<Dr....@t-...>]

Hi Erik, 

	i vaguely remember one game where one company has the right to lay 2
yellow tiles and others are not allowed to do so. 

	1841 .... Major Companies are allowed 2 while minor just one tile... 

	Regards, 

	Martin

[Rails-devel] Phase mgmt step 5: extra tile lays

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

I have committed and pushed code to move the specification of the number of
tiles (other than 1) that a company (type) can lay. It is moved from
CompanyManager.xml (<CompanyType>) to Game.xml, PhaseManager section
(<Phase><Tiles>).
As usual, properties defined for one phase propagate to all subsequent
phases, unless changed. This means that no longer a whole list of phases
needs be specified to which a certain number of tile lays applies.
Currently, the number of tile lays can only be specified per company type,
not per company.  I suppose there is no need for the latter, more
fine-grained option.

The games affected are 1825, 1835, 1851, 1880, 18EU and 18TN. 
I have not tested 1825 (too early in development) and 1880 (doesn't
currently run).

Erik.

Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP) - corrected

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

John,

Thanks for your report.  Many aspects of it sound familiar to me... :-)
I cannot promise that every aspect of it will (or even can) be addressed,
but your most of requests are reasonable and will be saved.

Some comments below.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Tuesday, October 11, 2011 3:08 AM
> To: rai...@li...
> Subject: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP) -
corrected
> 
> Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.
> 
> 1. I appreciate the changing of major company abbrevs to two letters, but
> the "Bay" president's share in starting packet seems to have been left
out.

This would cause saved game incompatibility. I have put it on the wiki
Legacy clean-ups wish-list.

> 2. During a starting packet purchase round, if a player cannot take any
action
> (has too little money to buy anything currently available) a popup appears
> "[name] cannot buy anything" with an OK button.  If two players are
skipped
> they are combined on one popup.  That's cute, but I'd prefer the turns be
> silently skipped.
> 
> Oddly enough, the stock round behavior is not the same.  If a player
cannot
> take any action on his stock turn (he has too little money to buy anything
> currently available, and owns nothing that can currently be sold) he still
gets a
> turn, even though "Pass" and "Autopass" are the only actions allowed.
> Again, I'd prefer the turn be silently skipped.

Same answer, although I will consider Stefan's suggestion to add 'silent'
player actions. 
Not sure if we should consider that as a permanent solution, or just a
compatibility hack.

> 3. If the start packet does not sell out in first round, the unsold shares
are not
> accounted for in the "Game Status" window.  They do not appear in the IPO
> column, bank pool, or anywhere else.  (I suggest adding a column for
> "Reserved" shares -- which would also include the 60% of PR that will be
> exchanged for privates and minors.)

Not a bad idea. 

> 4. The bug reported in Game Notes, where the game would hang if the By
> did not float in the first round, is no longer fatal, at least for me.
> 
> To be exact: As soon as the "Start Round" is passed out, focus moves to
the
> Game Status window, and its "Pass" and "Autopass" buttons change color as
> if they'd been enabled (but that window's name does NOT change to "Stock
> Round [n]", and a popup "Error: No action available" appears).
> 
> I worked around this by simply doing File -> Save on the menu bar and
saving
> the game.  (A restore wasn't needed.)  This moved the focus to the map
> window and made it an operating round, which of course is how it should
> have been.  When the OR finished, "Start Round" reappeared on the screen.
> 
> 5. Nit: The first operating round is still "0.1".
> 
> 6. The columns "Current" through "Tokens" on the Game Status window are
> too wide, apparently because they've been constrained to match the line
> showing the number of trains of each future type.  I would prefer that the
list
> of future trains be allowed to word-wrap, especially because it already
takes
> up two lines if any player owns two private companies.

An old wish. 
Being lucky* today, I finally found a solution on the Web: embed the text in
<html></html> and set the preferred size to (1,1).
Works nice.  Martin Brumm will also appreciate it.
Pushing it to the repo doesn't work yet though, so I have to fiddle with Git
again.

(* or so I though initially; to set that off, I just broke a nice vase at
home, a work of art.  Well, you can't have it all).

> 7. I really appreciate your enabling scroll bars on the Game Status window
so
> that the window no longer frequently and automatically changes size.
> 
> I propose a similar change to the Map window, which seems to frequently
> set itself to extend way beyond the screen (thus making me manually resize
> and move it) several times per game, either because the number of
> companies has changed or because a company laid a tile or token that
> required one of those columns in the list of companies to resize itself.

Yes, I also find that very annoying.  This was supposed to be fixed when we
added saving the window location and size, but apparently recreating the
window contents at each new OR breaks that.  I'll look for a fix, but the
mysteries of Java Swing still elude me often enough that I can't make any
promises. 

> (Conversely, the Tokens column does not resize itself when it gets so
narrow
> I can't see the number of tokens a company has left, and I wish it
> did!)

There you have it: sometimes resizing to make everything fit is good (in
this case), sometimes it's bad (in the above case). 
Either the window size is fixed, or it isn't - and it now seems to behave in
either way on the wrong moments. 

> 8. Unlike most companies, a PR token does not appear on the Stock Chart
> until the M2 is traded in to form the PR.  I propose that the PR token,
appear
> as soon as any player buys a share of PR, even though the shares can't be
> sold until the M2 is traded in.  (Other companies' shares can't be sold
until
> they have operated, but their tokens appear on the Stock Chart as soon as
> someone buys the president's share.)

The token is placed when a company is started, which in this case happens
with the M2 swap.
The 1835 rules also explicitly say that the token is placed at this time.
So, although I understand your wish, I don't think I'm going to put any
effort into it.

> 9. The Pfalzbahnen owner is being offered opportunities to lay a token
using
> its special power even when impossible (because the company currently
> operating has run out of tokens and/or already has one in the Pfalz hex).

Yes, that's a detail that still needs to be addressed.  I have no solution
for that yet. See also your next point. 

> 10. The Map window now allows a "Special" action to close private
companies
> voluntarily.  I don't think this is legal in 1835.  (I ran across this
while looking
> for a command to use Pfalz's power to lay a tile.  I think this "Special"
menu
> would be a much better place for tile- and token-laying powers to be,
rather
> than make the user click "No Tile" or "No Token" an extra time every turn.
> But I suppose that's a style issue.)

This is a stop-gap to enable closing privates that do not automatically
close according to the rules, such as the PfB above. This also applies to
the OBB.
Once all that works correctly, this option will be removed.

> 11. The tile-laying logic is mostly correct but still suggests tile lays
where the
> new tile is rotated in a way that makes it not connect to any station of
the
> company.  And there are situations where some tile lays are allowed but
> nothing gets suggested.

Indeed the tile laying process needs several refinements.  We all know, and
if it was easy it would probably have been done already. 
 
> (This game, the Pfalz owner did not have a major company before Phase 3,
> so I was unable to verify whether it still offers the Pfalz tile-lay on
every
> major-company turn of that player during yellow phase, which should never
> happen because the tile lay is impossible then.)
> 
> 12. The token-laying logic similarly still makes mistakes.  It suggests
every turn
> that BY lay a station marker in the south side of Nurnberg- Furth, even
> though it laid one on the north side in OR2 using the NF.

That would obviously be a bug.

> (Oddly enough, in a problem that resembles point 3 in reverse, the five PR
> tokens that are supposed to be reserved for exchanging minor company
> tokens
> *do* show up as available to be built.  Next time I'll try to build them
in
> arbitrary locations and see what happens -- both then and when the minor
> companies merge and there aren't any PR tokens for them.)

Interesting question: are these PR tokens really reserved?  I don't believe
the rules say so.

> 13. The revenue calculator consistently shows the correct runs for M6 on
the
> map but calculates their value as 20M too low (40 from green Hamburg to
> yellow Kiel, which should be 60).  Mousing over the map reveals the
> underlying problem: northwest Hamburg is value 20, not 40, in the tile
list (or
> wherever this information is stored for preprinted cities).

Right!  Strange that I have never noticed that.  Fixed.

> 14. The game reaches the point of the attached save file.  When the PR
buys
> the 5-train, SX has to discard a train (correctly changed from happening
upon
> purchase of the 4+4).  But then the game hangs while trying to merge the
> remaining private and minor companies.  I had to "undo" the 5-train
purchase
> (using the report window) to be able to save the game.
> 
> I've included the log as well.

I will investigate that later.

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

[<Dr....@t-...>]

Hi Erik, 

	since i am not yet officially in the list of contributors with access
i cant edit the wiki. 

	Can you grant me access ? 

	And yes i would still send my patches to the list first for comments
and checking :) 

	Regards, 

	Martin  

	  Von: "Erik Vos" <eri...@xs...>
 An: "'Development list for Rails: an 18xx game'"
<rai...@li...>
 Betreff: Re: [Rails-devel] Keeping compatibility (was: Test report:
1835 in Rails 1.5.1)
 Datum: Wed, 12 Oct 2011 12:23:25 +0200

 I have added a new section to the Wiki main page, called "Plans",
with a
 link to a new sub-page called "Legacy clean-ups".
 In that new page I have started to describe changes that are on the
 wish-list but have been postponed as these would cause saved game
 compatibility problems.
 The goal is to have a to-do list handy whenever we decide to build a
new
 version that is no longer compatible.

 See also my separate mail in response to John David Galt.

 Erik

 > -----Original Message-----
 > From: Stefan Frey [mailto:ste...@we...]
 > Sent: Tuesday, October 11, 2011 6:38 PM
 > To: Development list for Rails: an 18xx game
 > Subject: Re: [Rails-devel] Keeping compatibility (was: Test report:
1835
 in
 > Rails 1.5.1)
 > 
 > My current roadmap is to allow at least reading the save file fomat
of the
 > Rails 1.x series for Rails 2.0 to keep test games for the major
 redesigning.
 > 
 > When to introduce a new file format  used to write save files is
open and
 can
 > be 2.0 but it is also possible that it will occur later.
 > 
 > 
 > > This consideration has so far kept me from removing such actions.
 The
 one
 > > case I once did has caused me a lot of trouble.
 > >
 > > Ultimately we will have to bite the bullet.  There is already
quite some
 > > compatibility code that I would like to get rid of as well. Would
it be
 an
 > > idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it
means
 > > that we will have to rebuild all test cases.  Not just those in
the
 > > repository.
 > >
 > > Erik.

 ------------------------------------------------------------------------------
 All the data continuously generated in your IT infrastructure
contains a
 definitive record of customers, application performance, security
 threats, fraudulent activity and more. Splunk takes this data and
makes
 sense of it. Business sense. IT sense. Common sense.
 http://p.sf.net/sfu/splunk-d2d-oct
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18GA "gray towns" not counted as cities

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

Playing a TN game at the moment, will send it over when it's complete

On 10 October 2011 19:50, Stefan Frey <ste...@we...> wrote:
> I took the liberty to add the completed game to the test game suite, as we had
> no example game of 18GA so far.
>
> This reminds me that we still have no finished game of 1851, 18Kaas and 18TN
> so far. Could anyone contribute a save file?
>
> Stefan
>
>
> On Friday, October 07, 2011 11:43:42 pm Adam Badura wrote:
>> In the attached save G&F is about to make its OR turn. Don’t lay any tile
>> nor place any station. Just run. 6T (its only train) makes a route of 8
>> stops. It seems the gray border towns are not counted as cities (while
>> they should).
>>
>> We noticed this effect (in other companies too) after entering phase 5. But
>> its possible that either we just missed it earlier or the tracks and
>> trains were setup so that such routes were not possible anyway.
>>
>> I looked into tiles XML for 18GA and even tried to change those to Twons
>> but it seemed it didn’t help. Yet I might have done it the wrong way.
>>
>> Adam Badura
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

I have added a new section to the Wiki main page, called "Plans", with a
link to a new sub-page called "Legacy clean-ups".
In that new page I have started to describe changes that are on the
wish-list but have been postponed as these would cause saved game
compatibility problems.
The goal is to have a to-do list handy whenever we decide to build a new
version that is no longer compatible.

See also my separate mail in response to John David Galt.

Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, October 11, 2011 6:38 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Keeping compatibility (was: Test report: 1835
in
> Rails 1.5.1)
> 
> My current roadmap is to allow at least reading the save file fomat of the
> Rails 1.x series for Rails 2.0 to keep test games for the major
redesigning.
> 
> When to introduce a new file format  used to write save files is open and
can
> be 2.0 but it is also possible that it will occur later.
> 
> 
> > This consideration has so far kept me from removing such actions.  The
one
> > case I once did has caused me a lot of trouble.
> >
> > Ultimately we will have to bite the bullet.  There is already quite some
> > compatibility code that I would like to get rid of as well. Would it be
an
> > idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it means
> > that we will have to rebuild all test cases.  Not just those in the
> > repository.
> >
> > Erik.

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

The solution Brett suggested was implemented by me some time ago:
This enabled the auto-pass in the Start-Round.

It does not skip an action or player, but selects and executes the pass action 
automatically if it is the only possible action for a Player. The advantage of 
this is that does not break the save file compatibility.

I mentioned at that time that this behavior could be extended to the 
ShareRound if we check if the ActionSet only consists of Pass and Autopass.

At that time I did introduce the new message to the ReportBuffer (this creates 
the Popup before the next player without Autopass) to make players aware of 
the changed behavior.

Maybe the best solution is to make this configurable.
Something like AutoSkipPassingPlayers = {Silent, Warn, No}

Any thoughts what the default should be? This reminds me that in principle the 
configuration system allows different default profiles, maybe we should have 
one for beginner and one for experts?

Stefan




On Tuesday, October 11, 2011 03:36:23 pm Erik Vos wrote:
> I understand, but that would mean adding special compatibility code to skip
> such now 'silent' player actions when loading a saved file.
> 
> That's possible, but it's ugly.  For a long time, there has been such code
> in Game.load() to cope with one removed 'Done' action in (I believe) 1856.
>  That code is gone now. There is also such a case in 18EU, where I have
> not added compatibility code, but where have had to edit lots of old saved
> files to remove that extra 'Done', and I still occasionally encounter such
> saved files.
> 
> Erik.
> 
> > I didn't necessarily mean remove the actions from the log or save file. I
> > meant simply that we'd silently move the game forward until there's an
> > action needing player intervention.
> > 
> > ---Brett.
> > 
> > On Tue, Oct 11, 2011 at 5:56 AM, Erik Vos <eri...@xs...> wrote:
> > > I agree that tidying up these behaviours would be a good thing.
> > > 
> > > I think removing popups is easy to do.  Pressing the 'OK' on such
> > > popups
> > 
> > does not count as a player action.
> > 
> > > But removing unnecessary 'Pass' and 'Done' actions is a different
> > > matter,
> > 
> > because it has a bad side effect: all saved games that contain at least
> > one such removed action will no longer load. At least not without
> > special compatibility code to detect and catch such cases (and I'm not
> > sure if it's feasible at all).  This is especially bad for the
> > developers, who heavily rely on sometimes pretty old saved files for
> > testing.
> > 
> > > This consideration has so far kept me from removing such actions.  The
> > > one
> > 
> > case I once did has caused me a lot of trouble.
> > 
> > > Ultimately we will have to bite the bullet.  There is already quite
> > > some
> > 
> > compatibility code that I would like to get rid of as well.
> > 
> > > Would it be an idea to set this as a goal for Rails 2.0?  Or 2.1? 
> > > Remember: it
> > 
> > means that we will have to rebuild all test cases.  Not just those in the
> > repository.
> > 
> > > Erik.
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Release strategy (was: Rails 1.5.1 available)

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

I have a clear preference here: 1.x.y  releases with bug-fixes only. 
As soon as we add new features increase the second digit. 
If those changes are small or large is difficult to decide.

The version number is important for the user to understand if he can expect 
new features (potentially less stable) or only bug-fixes (more stable).

So pbem-player should always be able upgrade to a new 1.x.y, but should stay 
inside that branch if they prefer to finish the game without new hassle.

Given the previous release schedules I expect to see 1.x releases in the same 
frequency we had previously between 1.x.y releases anyway.

Stefan

> 
> For completeness sake, just one more remark: IMO 3rd-digit releases should
> not be reserved for bug fixes only. Small improvements, and perhaps even
> not so small ones, should be included as well.  I have a feeling that our
> users are much better testers than that we are, so withholding updates
> until we think these are really stable might backfire.  I'd rather have a
> bug reported sooner than later.
> 
> Erik.

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

My current roadmap is to allow at least reading the save file fomat of the 
Rails 1.x series for Rails 2.0 to keep test games for the major redesigning.

When to introduce a new file format  used to write save files is open and can 
be 2.0 but it is also possible that it will occur later.


> This consideration has so far kept me from removing such actions.  The one
> case I once did has caused me a lot of trouble.
> 
> Ultimately we will have to bite the bullet.  There is already quite some
> compatibility code that I would like to get rid of as well. Would it be an
> idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it means
> that we will have to rebuild all test cases.  Not just those in the
> repository.
> 
> Erik.
> 

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

I understand, but that would mean adding special compatibility code to skip such now 'silent' player actions when loading a saved file.

That's possible, but it's ugly.  For a long time, there has been such code in Game.load() to cope with one removed 'Done' action in (I believe) 1856.  That code is gone now.
There is also such a case in 18EU, where I have not added compatibility code, but where have had to edit lots of old saved files to remove that extra 'Done', and I still occasionally encounter such saved files.

Erik.

> 
> I didn't necessarily mean remove the actions from the log or save file. I
> meant simply that we'd silently move the game forward until there's an
> action needing player intervention.
> 
> ---Brett.
> 
> 
> 
> On Tue, Oct 11, 2011 at 5:56 AM, Erik Vos <eri...@xs...> wrote:
> > I agree that tidying up these behaviours would be a good thing.
> >
> > I think removing popups is easy to do.  Pressing the 'OK' on such popups
> does not count as a player action.
> >
> > But removing unnecessary 'Pass' and 'Done' actions is a different matter,
> because it has a bad side effect: all saved games that contain at least one
> such removed action will no longer load. At least not without special
> compatibility code to detect and catch such cases (and I'm not sure if it's
> feasible at all).  This is especially bad for the developers, who heavily rely on
> sometimes pretty old saved files for testing.
> >
> > This consideration has so far kept me from removing such actions.  The one
> case I once did has caused me a lot of trouble.
> >
> > Ultimately we will have to bite the bullet.  There is already quite some
> compatibility code that I would like to get rid of as well.
> > Would it be an idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it
> means that we will have to rebuild all test cases.  Not just those in the
> repository.
> >
> > Erik.

Re: [Rails-devel] Branching (was: Rails 1.5.1 available)

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

The short answer: If the stash isn't the right tool, just commit the
work, then change branches.

The slightly longer answer:  As long as your changes remain
unpublished, you can do pretty much whatever you want to your change
history. Once it's published, if you revise the history, it screws up
everyone pulling from that tree. The big thing to remember is that git
cares about *history*, not individual files or bits of code or
anything else.

So, if you commit unfinished work to your local branch and want to
come back later and finish it...  you can, with 'git commit --amend'.

Also, many of git's commands have an "--interactive" flag that allows
you to get very fine grained about what stuff is committed in which
order.

---Brett.



On Tue, Oct 11, 2011 at 6:33 AM, Erik Vos <eri...@xs...> wrote:
> Small changes and fixes I'm currently doing directly in the master branch.
> For more substantial work I create local branches, that I merge into master
> before pushing to the repo.
>
> I have one problem with branching, though: you can't switch branches easily
> if you have uncommitted work.  And I don't like creating commits for small
> bits and pieces.
>
> I know you can use 'git stash' to put away uncommitted work (index
> included), but git stash does not seem to honour .gitignore.  Or perhaps its
> Egit's handling of 'git add'.
> Yesterday I tried stashing for the first time, and 'git stash pop' failed on
> 18xx.log files that are included in my ignore files. (I think these logs are
> created by JUnit test runs. Perhaps I have just badly configured my log
> location).
>
> At least one would expect that the index would be saved when switching
> branches, but that does not seem to be the case. And stashing is a hassle.
> This is my only major gripe with Git so far.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> > IMO, it's easier to leave master as the lineage of stable changes and
>> > do any new development in (usually local) branches that can be merged
>> > into the stable trunk when they're ready.
>> >
>> > In git, branches and tags are both very very cheap (and fast), unlike
>> > SVN. So, if you want to have all development happen in master, then
>> > branch off for stable releases, we can do that too.
>>
>> Substantial changes have still should be done inside separate branches,
> like
>> my start of refactoring some parts in the Rails 2.0 branch.
>> Stefan
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

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

I didn't necessarily mean remove the actions from the log or save
file. I meant simply that we'd silently move the game forward until
there's an action needing player intervention.

---Brett.



On Tue, Oct 11, 2011 at 5:56 AM, Erik Vos <eri...@xs...> wrote:
> I agree that tidying up these behaviours would be a good thing.
>
> I think removing popups is easy to do.  Pressing the 'OK' on such popups does not count as a player action.
>
> But removing unnecessary 'Pass' and 'Done' actions is a different matter, because it has a bad side effect: all saved games that contain at least one such removed action will no longer load. At least not without special compatibility code to detect and catch such cases (and I'm not sure if it's feasible at all).  This is especially bad for the developers, who heavily rely on sometimes pretty old saved files for testing.
>
> This consideration has so far kept me from removing such actions.  The one case I once did has caused me a lot of trouble.
>
> Ultimately we will have to bite the bullet.  There is already quite some compatibility code that I would like to get rid of as well.
> Would it be an idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it means that we will have to rebuild all test cases.  Not just those in the repository.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Tuesday, October 11, 2011 3:19 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP)
>>
>> On Mon, Oct 10, 2011 at 8:13 PM, John David Galt
>> <jd...@di...> wrote:
>> > Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.
>> >
>> > 2. During a starting packet purchase round, if a player cannot take
>> > any action (has too little money to buy anything currently available)
>> > a popup appears "[name] cannot buy anything" with an OK button.  If
>> > two players are skipped they are combined on one popup.  That's cute,
>> > but I'd prefer the turns be silently skipped.
>> >
>> > Oddly enough, the stock round behavior is not the same.  If a player
>> > cannot take any action on his stock turn (he has too little money to
>> > buy anything currently available, and owns nothing that can currently
>> > be sold) he still gets a turn, even though "Pass" and "Autopass" are
>> > the only actions allowed.  Again, I'd prefer the turn be silently skipped.
>> >
>>
>> My suggestion is that these behaviors should:
>>
>> 1. Be consistent.
>> 2. Have a preference for whether the user wants to explicitly hit "next" (or
>> an equivalent) or automatically skip no-op actions.
>>
>> ---Brett.
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security threats,
>> fraudulent activity and more. Splunk takes this data and makes sense of it.
>> Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Branching (was: Rails 1.5.1 available)

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

Thanks, Stefan.  I'll keep your advices.

Just found that Egit's commit window has an amend button, which even seems
to allow changing the commit message.  So there is hope, even for me.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, October 11, 2011 12:50 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Branching (was: Rails 1.5.1 available)
> 
> Erik:
> quick response how to use git:
> 
> My usage pattern is now to use egit only read-only.
> I submit all git commands using the CLI. I find egit for active usage to
clumsy.
> However egit updates quickly after a git command (and if I am in a hurry
> pressing F5 usually inits an immediate update).
> 
> Committing minor changes is not an issue for me, as you can easily use git
> commit-a --amend which adds the recent changes to the previous commit.
> So usually I have a first commit with
> git commit -a -m "what I am currently working on"
> followed by a sequence of git commit -a --amend
> 
> Even if use individual commits you can always combine those with git
rebase
> -i HEAD~3 to modify and combine the latest three commits.
> And this can always be aborted using
> git rebase --abort
> or reverted with
> git reset --hard
> 
> And if you have local branches anyway you will usually rebase the commits
> before moving (rebasing) them into the master.
> 
> I had no use for stash until now.
> 
> Stefan
> 
> 
> On Tuesday, October 11, 2011 12:33:46 pm Erik Vos wrote:
> > Small changes and fixes I'm currently doing directly in the master
branch.
> > For more substantial work I create local branches, that I merge into
> > master before pushing to the repo.
> >
> > I have one problem with branching, though: you can't switch branches
> > easily if you have uncommitted work.  And I don't like creating
> > commits for small bits and pieces.
> >
> > I know you can use 'git stash' to put away uncommitted work (index
> > included), but git stash does not seem to honour .gitignore.  Or
> > perhaps its Egit's handling of 'git add'.
> > Yesterday I tried stashing for the first time, and 'git stash pop'
> > failed on 18xx.log files that are included in my ignore files. (I
> > think these logs are created by JUnit test runs. Perhaps I have just
> > badly configured my log location).
> >
> > At least one would expect that the index would be saved when switching
> > branches, but that does not seem to be the case. And stashing is a
hassle.
> > This is my only major gripe with Git so far.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > >
> > > > IMO, it's easier to leave master as the lineage of stable changes
> > > > and do any new development in (usually local) branches that can be
> > > > merged into the stable trunk when they're ready.
> > > >
> > > > In git, branches and tags are both very very cheap (and fast),
> > > > unlike SVN. So, if you want to have all development happen in
> > > > master, then branch off for stable releases, we can do that too.
> > >
> > > Substantial changes have still should be done inside separate
> > > branches,
> >
> > like
> >
> > > my start of refactoring some parts in the Rails 2.0 branch.
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > --- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Branching (was: Rails 1.5.1 available)

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

Erik:
quick response how to use git:

My usage pattern is now to use egit only read-only. 
I submit all git commands using the CLI. I find egit for active usage 
to clumsy. However egit updates quickly after a git command (and if I am in a 
hurry pressing F5 usually inits an immediate update).

Committing minor changes is not an issue for me, as
you can easily use
git commit-a --amend
which adds the recent changes to the previous commit.
So usually I have a first commit with
git commit -a -m "what I am currently working on"
followed by a sequence of git commit -a --amend

Even if use individual commits you can always combine those with
git rebase -i HEAD~3
to modify and combine the latest three commits.
And this can always be aborted using
git rebase --abort
or reverted with
git reset --hard

And if you have local branches anyway you will usually rebase the commits 
before moving (rebasing) them into the master.

I had no use for stash until now.

Stefan


On Tuesday, October 11, 2011 12:33:46 pm Erik Vos wrote:
> Small changes and fixes I'm currently doing directly in the master branch.
> For more substantial work I create local branches, that I merge into master
> before pushing to the repo.
> 
> I have one problem with branching, though: you can't switch branches easily
> if you have uncommitted work.  And I don't like creating commits for small
> bits and pieces.
> 
> I know you can use 'git stash' to put away uncommitted work (index
> included), but git stash does not seem to honour .gitignore.  Or perhaps
> its Egit's handling of 'git add'.
> Yesterday I tried stashing for the first time, and 'git stash pop' failed
> on 18xx.log files that are included in my ignore files. (I think these
> logs are created by JUnit test runs. Perhaps I have just badly configured
> my log location).
> 
> At least one would expect that the index would be saved when switching
> branches, but that does not seem to be the case. And stashing is a hassle.
> This is my only major gripe with Git so far.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > 
> > > IMO, it's easier to leave master as the lineage of stable changes and
> > > do any new development in (usually local) branches that can be merged
> > > into the stable trunk when they're ready.
> > > 
> > > In git, branches and tags are both very very cheap (and fast), unlike
> > > SVN. So, if you want to have all development happen in master, then
> > > branch off for stable releases, we can do that too.
> > 
> > Substantial changes have still should be done inside separate branches,
> 
> like
> 
> > my start of refactoring some parts in the Rails 2.0 branch.
> > Stefan
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel