rails-devel — List for discussion of Rails development

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

Hi Stefan, 

	if i understand you right, there will be: 

	- a branch 1.6.x that should get fixes for "released games and core
parts". 

	- a branch master(1.x) that should be available for new developments
outside of your work for 2.0 

	- a branch 2.0 that will be available for testing and merge tests
somewhere in the future where you expect someone(might be you or
someone else to port the additions we did to the game after 1.5. 

	If thats right, thats ok with me :) (my 2 c for whats it worth till
Erik saves my ass again :)) 

	Regards,
Martin  

	  Von: Stefan Frey <ste...@we...>
 An: rai...@li...
 Betreff: Re: [Rails-devel] Releasing 1.6.1 this weekend?
 Datum: Sun, 29 Jan 2012 18:26:12 +0100

 Frederick:
 Yes I will create 1.6.x after that release.
 I am happy for everyone who pushes their changes to both branches, 
 however I did not want to make this a requirement.
 Rails 1.5.x will not be deleted due to Brett asking for keeping all 
 releases re-creatable from the repo.
 Stefan

 On 01/29/2012 06:17 PM, Frederick Weld wrote:
 > Stefan:
 > No problem, I didn't perceive this as blaming. On top of that,
you're
 > right that some of my commits are prefixed by "fixed..." but relate
to
 > fixes to new (and not yet released) features.
 >
 > Having a branch labelled 1.6.x for hotfixes would be what I was
 > looking for. I didn't merge my fixes to the release branch since I
 > only saw 1.5.x on the remote and wasn't sure whether I was supposed
to
 > merge into that. So, you will create that 1.6.x branch and remove
 > 1.5.x?
 >
 > -- Frederick
 >
 > On Sun, Jan 29, 2012 at 6:05 PM, Stefan Frey  wrote:
 >> Frederick:
 >> it was not my intention to blame anyone for that:
 >>
 >> It is only the fact that simply filtering for "fix" in the
short-log window of
 >> a git-gui is misleading (which shows many more fixes than you
refer to below).
 >>
 >> Again it is not a blame, I was simply surprised by the number of
commits we
 >> see recently, which is a good and not a bad thing.
 >>
 >> The separation is already there, see my previous mail to Martin. I
preferred
 >> to create a new branch for the maintenance of each minor release
to avoid
 >> merging the "bug-fix" branch with the "development" branch after a
minor
 >> release.
 >>
 >> Stefan
 >>
 >>
 >>
 >> On Sunday, January 29, 2012 05:50:52 PM Frederick Weld wrote:
 >>> Stefan:
 >>> You're right that almost all work done are new features. But for
the
 >>> separation of features/fixes, I always tried to be very clear in
the
 >>> commits. From my point of view, my bug fix commits are:
 >>>
 >>> autosave: 9d832d70a9f91944f1e1d8fba124f97c00f097cd
 >>> default game options: ee46d990d508904fc6a542f20f8b4c30c53f4203
 >>> report window during timewarp:
397883e62ab8aec92b509016b5b37dec1ade89ea
 >>>
 >>> In my opinion, the two options would be either 1.6.1 bug-fix-only
or
 >>> 1.7 with full features. (without having a preference for any of
them)
 >>>
 >>> BTW: If we want to separate bug fix and feature dev more clearly
in
 >>> future, I would propose to use a new/specific branch "release".
 >>> Hotfixes are merged into both release and master (=feature dev).
Then,
 >>> it would be very easy to quickly make fixes available. (See
 >>> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)
 >>>
 >>> -- Frederick
 >>>
 >>>
----------------------------------------------------------------------------
 >>> -- Try before you buy = See our experts in action!
 >>> The most comprehensive online learning library for Microsoft
developers
 >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
CSS3, MVC3,
 >>> Metro Style Apps, more. Free future releases when you subscribe
now!
 >>> http://p.sf.net/sfu/learndevnow-dev2
 >>> _______________________________________________
 >>> Rails-devel mailing list
 >>> Rai...@li...
 >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
 >>
 >>
------------------------------------------------------------------------------
 >> Try before you buy = See our experts in action!
 >> The most comprehensive online learning library for Microsoft
developers
 >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 >> Metro Style Apps, more. Free future releases when you subscribe
now!
 >> http://p.sf.net/sfu/learndevnow-dev2
 >> _______________________________________________
 >> Rails-devel mailing list
 >> Rai...@li...
 >> https://lists.sourceforge.net/lists/listinfo/rails-devel
 >
 >
------------------------------------------------------------------------------
 > Try before you buy = See our experts in action!
 > The most comprehensive online learning library for Microsoft
developers
 > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 > Metro Style Apps, more. Free future releases when you subscribe
now!
 > http://p.sf.net/sfu/learndevnow-dev2
 > _______________________________________________
 > Rails-devel mailing list
 > Rai...@li...
 > https://lists.sourceforge.net/lists/listinfo/rails-devel

 ------------------------------------------------------------------------------
 Try before you buy = See our experts in action!
 The most comprehensive online learning library for Microsoft
developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-dev2
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 18TN bug fix and

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

I have received a bug report and a test game for 18TN from Bob Probst.
I have added both to master.

To my surprise the bug-fix did not conflict with the test-game:
The price of a buying the train from IPO is taken from the save file 
only without comparing it to the in-game price, thus it still reports 
that the train is bought for the old price.

> Here you are.  I noticed that Rails lists 6 trains as $630.  Whereas the
> rules state $600.  Everything else seems to be in order.

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Martin, Erik & Frederick:
this is a summary answer to the discussion that arose after this mail:

 From the beginning I clearly stated that it is my intention to make 
some changes to the internal working of Rails, especially to the state 
and model packages and then moving up to the round classes.

Master and Rails2.0 started to deviate after release 1.5 and I have
no intention to merge all commits after that now:

The main obstacle to merge things now is that there is no way to decide 
if they are functionally correct, as the Rails 2.0 does not even compile 
now. So I would not recommend anyone to merge at this point in time.

If the 1.x merges get merged and by whom later on is open: Simple bug 
fixes most likely can be merged easily, your stuff should be mergeable 
after a few changes, however other things will be more difficult, but 
not impossible.

Most likely Martin's argument is correct: Why waste the time to wait for 
Rails2.0 to start developing, if one has spare time to do so now.
In the worst case one can use the experience from that to add an even 
better implementation to Rails2.0 at the time the development of 2.0 
allows to do so.

So my main point is to keep the issue transparent to avoid 
disappointment later but I do not actively discouraging all of you who 
are keen to add new features which work immediately.
However I currently prefer to improve the base layer where everything 
can be built upon.

Stefan



On 01/29/2012 05:12 PM, Frederick Weld wrote:
> @Martin&  Erik:
> When reading this thread, I'm wondering how you will merge all these
> changes to the game engine into 2.0.
> Perhaps I'm missing some important information here, but as far as I
> know, all changes to game engine will be dropped when migrating to
> 2.0.
>
> @Stefan:
> Wouldn't it make sense if master was merged right now into 2.0 and,
> from that point in time on, everyone who changes master is responsible
> for also keeping 2.0 up-to-date? (still keeping two separate branches,
> of course, for retaining a working version )
> That would have the benefit that everyone can directly perceive
> whether his changes will be valid in 2.0 (and, if not, how to adjust).
> If only merging once 2.0 is ready, we will have to deal with
> incompatible commits that were performed several months ago the
> content/interdependencies of which have long been forgotten...
> At least for me, I would prefer double-maintenance now to that
> situation in the near future.
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

Frederick:
Yes I will create 1.6.x after that release.
I am happy for everyone who pushes their changes to both branches, 
however I did not want to make this a requirement.
Rails 1.5.x will not be deleted due to Brett asking for keeping all 
releases re-creatable from the repo.
Stefan


On 01/29/2012 06:17 PM, Frederick Weld wrote:
> Stefan:
> No problem, I didn't perceive this as blaming. On top of that, you're
> right that some of my commits are prefixed by "fixed..." but relate to
> fixes to new (and not yet released) features.
>
> Having a branch labelled 1.6.x for hotfixes would be what I was
> looking for. I didn't merge my fixes to the release branch since I
> only saw 1.5.x on the remote and wasn't sure whether I was supposed to
> merge into that. So, you will create that 1.6.x branch and remove
> 1.5.x?
>
> -- Frederick
>
> On Sun, Jan 29, 2012 at 6:05 PM, Stefan Frey<ste...@we...>  wrote:
>> Frederick:
>> it was not my intention to blame anyone for that:
>>
>> It is only the fact that simply filtering for "fix" in the short-log window of
>> a git-gui is misleading (which shows many more fixes than you refer to below).
>>
>> Again it is not a blame, I was simply surprised by the number of commits we
>> see recently, which is a good and not a bad thing.
>>
>> The separation is already there, see my previous mail to Martin. I preferred
>> to create a new branch for the maintenance of each minor release to avoid
>> merging the "bug-fix" branch with the "development" branch after a minor
>> release.
>>
>> Stefan
>>
>>
>>
>> On Sunday, January 29, 2012 05:50:52 PM Frederick Weld wrote:
>>> Stefan:
>>> You're right that almost all work done are new features. But for the
>>> separation of features/fixes, I always tried to be very clear in the
>>> commits. From my point of view, my bug fix commits are:
>>>
>>> autosave: 9d832d70a9f91944f1e1d8fba124f97c00f097cd
>>> default game options: ee46d990d508904fc6a542f20f8b4c30c53f4203
>>> report window during timewarp: 397883e62ab8aec92b509016b5b37dec1ade89ea
>>>
>>> In my opinion, the two options would be either 1.6.1 bug-fix-only or
>>> 1.7 with full features. (without having a preference for any of them)
>>>
>>> BTW: If we want to separate bug fix and feature dev more clearly in
>>> future, I would propose to use a new/specific branch "release".
>>> Hotfixes are merged into both release and master (=feature dev). Then,
>>> it would be very easy to quickly make fixes available. (See
>>> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)
>>>
>>> -- Frederick
>>>
>>> ----------------------------------------------------------------------------
>>> -- Try before you buy = See our experts in action!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-dev2
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Releasing 1.6.1 this weekend?

[Frederick W. <fre...@go...>]

Stefan:
No problem, I didn't perceive this as blaming. On top of that, you're
right that some of my commits are prefixed by "fixed..." but relate to
fixes to new (and not yet released) features.

Having a branch labelled 1.6.x for hotfixes would be what I was
looking for. I didn't merge my fixes to the release branch since I
only saw 1.5.x on the remote and wasn't sure whether I was supposed to
merge into that. So, you will create that 1.6.x branch and remove
1.5.x?

-- Frederick

On Sun, Jan 29, 2012 at 6:05 PM, Stefan Frey <ste...@we...> wrote:
> Frederick:
> it was not my intention to blame anyone for that:
>
> It is only the fact that simply filtering for "fix" in the short-log window of
> a git-gui is misleading (which shows many more fixes than you refer to below).
>
> Again it is not a blame, I was simply surprised by the number of commits we
> see recently, which is a good and not a bad thing.
>
> The separation is already there, see my previous mail to Martin. I preferred
> to create a new branch for the maintenance of each minor release to avoid
> merging the "bug-fix" branch with the "development" branch after a minor
> release.
>
> Stefan
>
>
>
> On Sunday, January 29, 2012 05:50:52 PM Frederick Weld wrote:
>> Stefan:
>> You're right that almost all work done are new features. But for the
>> separation of features/fixes, I always tried to be very clear in the
>> commits. From my point of view, my bug fix commits are:
>>
>> autosave: 9d832d70a9f91944f1e1d8fba124f97c00f097cd
>> default game options: ee46d990d508904fc6a542f20f8b4c30c53f4203
>> report window during timewarp: 397883e62ab8aec92b509016b5b37dec1ade89ea
>>
>> In my opinion, the two options would be either 1.6.1 bug-fix-only or
>> 1.7 with full features. (without having a preference for any of them)
>>
>> BTW: If we want to separate bug fix and feature dev more clearly in
>> future, I would propose to use a new/specific branch "release".
>> Hotfixes are merged into both release and master (=feature dev). Then,
>> it would be very easy to quickly make fixes available. (See
>> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)
>>
>> -- Frederick
>>
>> ----------------------------------------------------------------------------
>> -- Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

Frederick:
it was not my intention to blame anyone for that:

It is only the fact that simply filtering for "fix" in the short-log window of 
a git-gui is misleading (which shows many more fixes than you refer to below).

Again it is not a blame, I was simply surprised by the number of commits we 
see recently, which is a good and not a bad thing.

The separation is already there, see my previous mail to Martin. I preferred 
to create a new branch for the maintenance of each minor release to avoid
merging the "bug-fix" branch with the "development" branch after a minor 
release.

Stefan



On Sunday, January 29, 2012 05:50:52 PM Frederick Weld wrote:
> Stefan:
> You're right that almost all work done are new features. But for the
> separation of features/fixes, I always tried to be very clear in the
> commits. From my point of view, my bug fix commits are:
> 
> autosave: 9d832d70a9f91944f1e1d8fba124f97c00f097cd
> default game options: ee46d990d508904fc6a542f20f8b4c30c53f4203
> report window during timewarp: 397883e62ab8aec92b509016b5b37dec1ade89ea
> 
> In my opinion, the two options would be either 1.6.1 bug-fix-only or
> 1.7 with full features. (without having a preference for any of them)
> 
> BTW: If we want to separate bug fix and feature dev more clearly in
> future, I would propose to use a new/specific branch "release".
> Hotfixes are merged into both release and master (=feature dev). Then,
> it would be very easy to quickly make fixes available. (See
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)
> 
> -- Frederick
> 
> ----------------------------------------------------------------------------
> -- Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Sunday, January 29, 2012 5:13 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1880 Implementation: Opinions wanted
> 
> @Martin & Erik:
> When reading this thread, I'm wondering how you will merge all these
> changes to the game engine into 2.0.
> Perhaps I'm missing some important information here, but as far as I know,
> all changes to game engine will be dropped when migrating to 2.0.

>From my POV, that's up to Stefan.  My current position is, that I'm only
feeling responsible for 1.x.  If and when that will change, I can't say
right now.

Erik.
 
> @Stefan:
> Wouldn't it make sense if master was merged right now into 2.0 and, from
> that point in time on, everyone who changes master is responsible for also
> keeping 2.0 up-to-date? (still keeping two separate branches, of course,
for
> retaining a working version ) That would have the benefit that everyone
can
> directly perceive whether his changes will be valid in 2.0 (and, if not,
how to
> adjust).
> If only merging once 2.0 is ready, we will have to deal with incompatible
> commits that were performed several months ago the
> content/interdependencies of which have long been forgotten...
> At least for me, I would prefer double-maintenance now to that situation
in
> the near future.
> 
> --Frederick
> 
>
----------------------------------------------------------------------------
--
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

[Frederick W. <fre...@go...>]

Martin:
> Regarding your implementations, can you be sure that those work in 2.0 yet ?

The probability of merge issues is very low as I have restricted all
my implementations on the UI / Sound layer (the exceptions to this
have been reverted yesterday).
But you're right that, even if my commits pass the merge hurdle,
functionality is a completely different story.

-- Frederick

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

Martin,
see answers below.
Stefan

On Sunday, January 29, 2012 05:44:06 PM Dr....@t-... wrote:
> Hi Stefan,
> 
> 	1:) Stefan your email adress is way of :)

Thx, some side-effect from the recent system update.

> 
> 	2) i would love to see a maintenance branch, a development branch
> based on the 2.0 as fast as possible and in the mean time a
> development branch based on the latest 1.6.

In principle that was the setup for rails 1.5.x:

master => development branch for 1.x
rails2.0 => development branch for 2.0
rails1.5.x => maintenance branch for 1.5.x

What I did as release manager is to pick the bug-fixes from master into 
rails1.5.x and then releasing from there.

This process is even documented our wiki, see
http://sourceforge.net/apps/mediawiki/rails/index.php?title=Release_Management

(Reminds me that nearly all steps of the last section is automated already and 
I should update the walk-through accordingly.)

> 
> 	So lets keep 1.6.x as maint 1.x as development and of course 2.x as
> major Release.

Do you vote for releasing all changes (including those for 1880) now as part 
of 1.6.x or keep them in development only and release them at 1.7. only?

> 
> 	  Von: StefanFrey@dhcppc0
>  An: "Development list for Rails: an 18xx game"
> <rai...@li...>
>  Betreff: Re: [Rails-devel] Releasing 1.6.1 this weekend?
>  Datum: Sun, 29 Jan 2012 17:33:30 +0100
> 
>  All:
>  Another follow up before I release.
> 
>  Originally I intended to restrict the maintenance releases to bug
> fixes only.
>  Reason was that users should expect to be a maintenance release to be
>  more stable than any one before. I deviated a little from this by
> releasing
>  the background maps in between, however they were optional only.
> 
>  However there are several issues now:
> 
>  * To my surprise there has been a burst of the commit frequency to
> rails 1.x
>  since I announced rails 2.0. So there are much more commits as
> expected and
>  due to my focus on the 2.0 branch I have not followed them that
> closely.
> 
>  * There have been only one or two clear bug-fixes since 1.6.0, so
> releasing
>  only those is possible.
> 
>  * Reading some commit statements sometimes it is likely that the
> commit
>  contains both improvement and bug fix.
> 
>  So my Question is:
> 
>  -> Continue as before and release 1.6.1 with only some few bug fixes.
> 
>  -> Go back to the old style: Release everything and ignore the
> intention
>  of maintenance releases.
> 
>  Stefan
> 
>  Remark: Unfortunately I forgot to push the v1.6.0 tag, so one has to
> go back
>  to the date 23/12/2011 or search for 1.6.0 in the commit annotations.
> 
>  On Saturday, January 28, 2012 02:07:14 PM ste...@we... wrote:
>  > All:
>  > as I have been pretty busy and the recent commits of Erik require
> 
> branching
> 
>  > the master for a 1.6.x release series, the release of 1.6.1 got
> 
> delayed:
>  > Hope do get it done until Monday latest.
>  > 
>  > The upgrade to OpenSUSE 12.1 today does not help either, as it
> 
> requires
> 
>  > installing Eclipse afresh (which is not part of the suse repos
>  > unfortunately).
>  > 
>  > Due to the upgrade I also pushed my current local Rails 2.0 branch,
> 
> which
> 
>  > still does not compile, however it is close (only 32 errors
> 
> remaining, down
> 
>  > from around 600 at top). So stay tuned for more updates in the not
> 
> too
> 
>  > distant future.
>  > 
>  > Stefan
>  > 
>  > 
>  > -----Ursprüngliche Nachricht-----
>  > Von: "Stefan Frey"
>  > Gesendet: Jan 20, 2012 11:59:14 AM
>  > An: "Development list for Rails: an 18xx game"
>  > 
>  >  Betreff: [Rails-devel] Releasing 1.6.1
>  > 
>  > this weekend?
>  > 
>  > All:
>  > I plan to release 1.6.1. at the end of this weekend, as there are
> 
> quite a
> 
>  > few of Frederick changes are piling up.
>  > So keep last-minute fixes and changes rolling in ...
>  > 
>  > My intention is to update the 2.0 branch with my current local repo
> 
> this or
> 
>  > next weekend latest. Lots of stuff changed, so I hope to present
> 
> something
> 
>  > soon that is worth of feedback.
>  > 
>  > Stefan
> 
> ----------------------------------------------------------------------------
>  > -- Keep Your Developer Skills Current with LearnDevNow!
>  > The most comprehensive online learning library for Microsoft
> 
> developers
> 
>  > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> 
> MVC3,
> 
>  > Metro Style Apps, more. Free future releases when you subscribe
> 
> now!
> 
>  > http://p.sf.net/sfu/learndevnow-d2d
>  > _______________________________________________
>  > Rails-devel mailing list
>  > Rai...@li...
>  > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ----------------------------------------------------------------------------
>  > -- Try before you buy = See our experts in action!
>  > The most comprehensive online learning library for Microsoft
> 
> developers
> 
>  > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> 
> MVC3,
> 
>  > Metro Style Apps, more. Free future releases when you subscribe
> 
> now!
> 
>  > http://p.sf.net/sfu/learndevnow-dev2
>  > _______________________________________________
>  > Rails-devel mailing list
>  > Rai...@li...
>  > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>  ---------------------------------------------------------------------------
> --- Try before you buy = See our experts in action!
>  The most comprehensive online learning library for Microsoft
> developers
>  is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> MVC3,
>  Metro Style Apps, more. Free future releases when you subscribe now!
>  http://p.sf.net/sfu/learndevnow-dev2
>  _______________________________________________
>  Rails-devel mailing list
>  Rai...@li...
>  https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Releasing 1.6.1 this weekend?

[Frederick W. <fre...@go...>]

Stefan:
You're right that almost all work done are new features. But for the
separation of features/fixes, I always tried to be very clear in the
commits. From my point of view, my bug fix commits are:

autosave: 9d832d70a9f91944f1e1d8fba124f97c00f097cd
default game options: ee46d990d508904fc6a542f20f8b4c30c53f4203
report window during timewarp: 397883e62ab8aec92b509016b5b37dec1ade89ea

In my opinion, the two options would be either 1.6.1 bug-fix-only or
1.7 with full features. (without having a preference for any of them)

BTW: If we want to separate bug fix and feature dev more clearly in
future, I would propose to use a new/specific branch "release".
Hotfixes are merged into both release and master (=feature dev). Then,
it would be very easy to quickly make fixes available. (See
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

-- Frederick

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

Hi Stefan, 

	1:) Stefan your email adress is way of :) 

	2) i would love to see a maintenance branch, a development branch
based on the 2.0 as fast as possible and in the mean time a
development branch based on the latest 1.6. 

	So lets keep 1.6.x as maint 1.x as development and of course 2.x as
major Release.  

	  Von: StefanFrey@dhcppc0
 An: "Development list for Rails: an 18xx game"
<rai...@li...>
 Betreff: Re: [Rails-devel] Releasing 1.6.1 this weekend?
 Datum: Sun, 29 Jan 2012 17:33:30 +0100

 All:
 Another follow up before I release. 

 Originally I intended to restrict the maintenance releases to bug
fixes only.
 Reason was that users should expect to be a maintenance release to be
 more stable than any one before. I deviated a little from this by
releasing 
 the background maps in between, however they were optional only.

 However there are several issues now:

 * To my surprise there has been a burst of the commit frequency to
rails 1.x 
 since I announced rails 2.0. So there are much more commits as
expected and 
 due to my focus on the 2.0 branch I have not followed them that
closely.

 * There have been only one or two clear bug-fixes since 1.6.0, so
releasing 
 only those is possible.

 * Reading some commit statements sometimes it is likely that the
commit
 contains both improvement and bug fix.

 So my Question is:

 -> Continue as before and release 1.6.1 with only some few bug fixes.

 -> Go back to the old style: Release everything and ignore the
intention
 of maintenance releases.

 Stefan

 Remark: Unfortunately I forgot to push the v1.6.0 tag, so one has to
go back 
 to the date 23/12/2011 or search for 1.6.0 in the commit annotations.

 On Saturday, January 28, 2012 02:07:14 PM ste...@we... wrote:
 > All:
 > as I have been pretty busy and the recent commits of Erik require
branching
 > the master for a 1.6.x release series, the release of 1.6.1 got
delayed:
 > Hope do get it done until Monday latest.
 > 
 > The upgrade to OpenSUSE 12.1 today does not help either, as it
requires
 > installing Eclipse afresh (which is not part of the suse repos
 > unfortunately).
 > 
 > Due to the upgrade I also pushed my current local Rails 2.0 branch,
which
 > still does not compile, however it is close (only 32 errors
remaining, down
 > from around 600 at top). So stay tuned for more updates in the not
too
 > distant future.
 > 
 > Stefan
 > 
 > 
 > -----Ursprüngliche Nachricht-----
 > Von: "Stefan Frey" 
 > Gesendet: Jan 20, 2012 11:59:14 AM
 > An: "Development list for Rails: an 18xx game"
 >  Betreff: [Rails-devel] Releasing 1.6.1
 > this weekend?
 > 
 > All:
 > I plan to release 1.6.1. at the end of this weekend, as there are
quite a
 > few of Frederick changes are piling up.
 > So keep last-minute fixes and changes rolling in ...
 > 
 > My intention is to update the 2.0 branch with my current local repo
this or
 > next weekend latest. Lots of stuff changed, so I hope to present
something
 > soon that is worth of feedback.
 > 
 > Stefan
 > 
 >
----------------------------------------------------------------------------
 > -- Keep Your Developer Skills Current with LearnDevNow!
 > The most comprehensive online learning library for Microsoft
developers
 > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 > Metro Style Apps, more. Free future releases when you subscribe
now!
 > http://p.sf.net/sfu/learndevnow-d2d
 > _______________________________________________
 > Rails-devel mailing list
 > Rai...@li...
 > https://lists.sourceforge.net/lists/listinfo/rails-devel
 > 
 > 
 >
----------------------------------------------------------------------------
 > -- Try before you buy = See our experts in action!
 > The most comprehensive online learning library for Microsoft
developers
 > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 > Metro Style Apps, more. Free future releases when you subscribe
now!
 > http://p.sf.net/sfu/learndevnow-dev2
 > _______________________________________________
 > Rails-devel mailing list
 > Rai...@li...
 > https://lists.sourceforge.net/lists/listinfo/rails-devel

 ------------------------------------------------------------------------------
 Try before you buy = See our experts in action!
 The most comprehensive online learning library for Microsoft
developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-dev2
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

Hi Frederik, 

	honestly i would prefer them to be moved to 2.0. But shall i wait
till Stefan has finished 2.0 so that one can implement and test
everything on 2.0 ? 

	Thats lost time (and more time imho then it should need to adapt
everything to 2.0). 

	Regarding your implementations, can you be sure that those work in
2.0 yet ? 

	So i think we will have to live with the split here and wait for
Stefan to bring 2.0 to a working condition. 

	Regards,
Martin

	  Von: Frederick Weld <fre...@go...>
 An: "Development list for Rails: an 18xx game"
<rai...@li...>
 Betreff: Re: [Rails-devel] 1880 Implementation: Opinions wanted
 Datum: Sun, 29 Jan 2012 17:12:56 +0100

 @Martin & Erik:
 When reading this thread, I'm wondering how you will merge all these
 changes to the game engine into 2.0.
 Perhaps I'm missing some important information here, but as far as I
 know, all changes to game engine will be dropped when migrating to
 2.0.

 @Stefan:
 Wouldn't it make sense if master was merged right now into 2.0 and,
 from that point in time on, everyone who changes master is
responsible
 for also keeping 2.0 up-to-date? (still keeping two separate
branches,
 of course, for retaining a working version )
 That would have the benefit that everyone can directly perceive
 whether his changes will be valid in 2.0 (and, if not, how to
adjust).
 If only merging once 2.0 is ready, we will have to deal with
 incompatible commits that were performed several months ago the
 content/interdependencies of which have long been forgotten...
 At least for me, I would prefer double-maintenance now to that
 situation in the near future.

 --Frederick

 ------------------------------------------------------------------------------
 Try before you buy = See our experts in action!
 The most comprehensive online learning library for Microsoft
developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-dev2
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Releasing 1.6.1 this weekend?

[<Ste...@dh...>]

All:
Another follow up before I release. 

Originally I intended to restrict the maintenance releases to bug fixes only.
Reason was that users should expect to be a maintenance release to be
more stable than any one before. I deviated a little from this by releasing 
the background maps in between, however they were optional only.

However there are several issues now:

* To my surprise there has been a burst of the commit frequency to rails 1.x 
since I announced rails 2.0. So there are much more commits as expected and 
due to my focus on the 2.0 branch I have not followed them that closely.

* There have been only one or two clear bug-fixes since 1.6.0, so releasing 
only those is possible.

* Reading some commit statements sometimes it is likely that the commit
contains both improvement and bug fix.


So my Question is:

-> Continue as before and release 1.6.1 with only some few bug fixes.

-> Go back to the old style: Release everything and ignore the intention
of maintenance releases.

Stefan

Remark: Unfortunately I forgot to push the v1.6.0 tag, so one has to go back 
to the date 23/12/2011 or search for 1.6.0 in the commit annotations.


On Saturday, January 28, 2012 02:07:14 PM ste...@we... wrote:
> All:
> as I have been pretty busy and the recent commits of Erik require branching
> the master for a 1.6.x release series, the release of 1.6.1 got delayed:
> Hope do get it done until Monday latest.
> 
> The upgrade to OpenSUSE 12.1 today does not help either, as it requires
> installing Eclipse afresh (which is not part of the suse repos
> unfortunately).
> 
> Due to the upgrade I also pushed my current local Rails 2.0 branch, which
> still does not compile, however it is close (only 32 errors remaining, down
> from around 600 at top). So stay tuned for more updates in the not too
> distant future.
> 
> Stefan
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: "Stefan Frey" <ste...@we...>
> Gesendet: Jan 20, 2012 11:59:14 AM
> An: "Development list for Rails: an 18xx game"
> <rai...@li...> Betreff: [Rails-devel] Releasing 1.6.1
> this weekend?
> 
> All:
> I plan to release 1.6.1. at the end of this weekend, as there are quite a
> few of Frederick changes are piling up.
> So keep last-minute fixes and changes rolling in ...
> 
> My intention is to update the 2.0 branch with my current local repo this or
> next weekend latest. Lots of stuff changed, so I hope to present something
> soon that is worth of feedback.
> 
> Stefan
> 
> ----------------------------------------------------------------------------
> -- Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ----------------------------------------------------------------------------
> -- Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Implementation: Opinions wanted

[Frederick W. <fre...@go...>]

@Martin & Erik:
When reading this thread, I'm wondering how you will merge all these
changes to the game engine into 2.0.
Perhaps I'm missing some important information here, but as far as I
know, all changes to game engine will be dropped when migrating to
2.0.

@Stefan:
Wouldn't it make sense if master was merged right now into 2.0 and,
from that point in time on, everyone who changes master is responsible
for also keeping 2.0 up-to-date? (still keeping two separate branches,
of course, for retaining a working version )
That would have the benefit that everyone can directly perceive
whether his changes will be valid in 2.0 (and, if not, how to adjust).
If only merging once 2.0 is ready, we will have to deal with
incompatible commits that were performed several months ago the
content/interdependencies of which have long been forgotten...
At least for me, I would prefer double-maintenance now to that
situation in the near future.

--Frederick

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

My initial views:

 

a)       

Currently, there are two ways to assign rights to Players and to Companies: with SpecialProperties and with Rights.

SpecialProperties always (at least so far) come with acquired private companies.  In a game like 1835, the special property immediately transfers to the player owning the private, and I believe this is the way you should try to implement the 1880 private properties as well.  Implementing new special properties is not trivial, and I think that in many cases you will have to create new (either generic or 1880-specific) SpecialProperty subclasses.  Of course I’ll be willing to help you out.

 

I understand you would like to display such player-owned private rights in the UI.  This is not yet done anywhere.  A Rails principle is that players ought to know the game rules, and in this case, what special rights they have when owning certain privates (which *are* displayed). They can also look up private rights in the Info menu.  See 1830 for examples.

 

Right has been created for 1830 Coalfields and is  intended to take care of properties that are not linked to privates but can be acquired by everyone.  I have considered handling the Coalfields right as a SpecialProperty as well, but handling was too different to make that achievable without major changes.  I would think that the 1880 building rights should be implemented as Rights, but (as always) the proof of the pudding will be in the eating. 

 

As with all new generic items intended to cover new game-specific features that *may* have general impact, I consider the Rights implementation as provisional as long as it has not been proven to be able to cover multiple cases, and Rights definitely falls into this class.

 

a)       

I believe this is the same situation as we have with 1856 if the CGR has no train: it “borrows” the train that currently is on top of the IPO stack.  Effectively, it runs that train without ever getting it.  I think the same solution should apply to 1880.  So we don’t need a new portfolio: it already exists, and is called “IPO”.

 

As for displaying a borrowed train: if that doesn’t already happen in 1856, it’s probably a good idea to add it there too, so it would be a generic feature.  I would start checking out if updating TrainsModel could cover such a case, e.g. by adding a method ‘useBorrowedTrain (Portfolio ipo)’.  Passing a reference to IPO would cause displaying the first available IPO train in square brackets (for instance).  Passing null would switch that off and return to the normal display.

 

Erik.

 

 

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Sunday, January 29, 2012 12:22 AM
To: Rails Development
Subject: [Rails-devel] 1880 Implementation: Opinions wanted

 

Hi,

 

i would like to get some opinions for two todos next on my list.

 

a) Major Companies in 1880 have their tile laying rights bound to a "building" right. This will be determined not at creation of that company but at Start based on the director share type and the player chosing from a number of indefinetely available rights.

 

In Connect with that "semi-static" Right, the company in question will receive a numer of rights if the director of that company holds a private (Taiwan, Ferry, Bridge). Its not linked to the company but through the player to all companies he owns.

 

If i want to display those right i think i'll have to make use of the not yet fully implemented RightsModel Class. Any objections, different approach suggestions here ?

 

b) the train lending feature: For the Investors/Minor Companies the currently in the bank available train is used to determine the Revenue.

I would like to have that displayed in the companies portfolio and of course used in the revenue calculation.

 

I propose to generate a 4th heap/portfolio which will hold the not yet leased/lent trains and then use a leaseTrain method that will move those trains into the Minors portfolio upon start/event and move the already listed trains to the scrap heap.

 

Any ideas there ? Cause the low level approch of using the Portfolio mechanismn directly is not what should be done or? (Besides we dont have a removeTrain method thats visible outside of Portfolio for a reason anyway.)

 

Regards,

Martin

[Rails-devel] 1880 Implementation: Opinions wanted

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

Hi, 

	i would like to get some opinions for two todos next on my list. 

	a) Major Companies in 1880 have their tile laying rights bound to a
"building" right. This will be determined not at creation of that
company but at Start based on the director share type and the player
chosing from a number of indefinetely available rights. 

	In Connect with that "semi-static" Right, the company in question
will receive a numer of rights if the director of that company holds a
private (Taiwan, Ferry, Bridge). Its not linked to the company but
through the player to all companies he owns. 

	If i want to display those right i think i'll have to make use of the
not yet fully implemented RightsModel Class. Any objections, different
approach suggestions here ?

	b) the train lending feature: For the Investors/Minor Companies the
currently in the bank available train is used to determine the
Revenue. 

	I would like to have that displayed in the companies portfolio and of
course used in the revenue calculation. 

	I propose to generate a 4th heap/portfolio which will hold the not
yet leased/lent trains and then use a leaseTrain method that will move
those trains into the Minors portfolio upon start/event and move the
already listed trains to the scrap heap. 

	Any ideas there ? Cause the low level approch of using the Portfolio
mechanismn directly is not what should be done or? (Besides we dont
have a removeTrain method thats visible outside of Portfolio for a
reason anyway.) 

	Regards, 

	Martin

[Rails-devel] Several new sound options available

[Frederick W. <fre...@go...>]

Master now contains a lot of new sound options, encompassing both
- BGM: background music (5 parameterizable contexts)
- SFX: sound effects (17 distinct events), including special handling
(eg., length of set revenue sfx depends on the revenue amount (as in
RRT1))

As before:
- playing sounds (both bgm / sfx) is disabled by default
- sound content I use locally is not uploaded for copyright reasons.

In the following, I added some details about what has been done (all
details found in commit comments/java-doc).

--Frederick

=============================================
What has been changed in rails (apart from rails.sound.*) ?
=============================================

Game Engine (rails.game.*):
- Removal of all calls to the old BackgroundMusicManager (developed 2
months ago)
     --> Full compliance with layering and publish/subscriber paradigm
("Rails2.0 ready")
- GameManager(I) and PublicCompany(I) are extended with a
getter-method for already existing but externally required game models
(getCurrentRoundModel and getFloatedModel respectively).

Config:
- New option tag ("alwaysCallInit") for Config Items that init is
executed even from the game setup (GameSetup is one of the BGM
contexts)
- Added scrollbars to config window's tab panels (sfx has 17 options...).

Dynamic Report Window:
- corrected its status model: now time warp mode is set before the
goto associated with the clicked.

=============================================
What has happened in rails.sound.*? How does it work?
=============================================

Old BackgroundMusicManager removed and replaced by a new sound
framework (5 classes).

As a facade to the rest of rails, the Sound Manager is notified of
- processed events (by GameUIManager)
   - this covers most of the triggers of playing sounds
- model updates (by the respective models)- as an observer to the
relevant game models.
- rare case: direct notification from UI layer for non-action /
non-model change events (eg., set revenue without dividend decision).

Based on this input, several events / contexts are recognized:
- Background music (BGM) is configurable on a per-round-type and
per-phase basis. (currently 5 round types supported)
- There are 17 sound effects (SFX) types, of which
     - one is parameterizable (train type for buy train)
     - one is played for a varying amount of time (set revenue
depending on the revenue - similar to RRT1)

The recognition of input received by the framework is evaluated by the
event interpreter who
- triggers sound playing directly (straightforward cases)
- triggers sound context adjustment (complex case - eg. phase bgm)
    - which triggers in turn playing sounds

The framework also correctly handles these situations:
- timewarp (sfx disabled)
- game loading (sfx/music disabled)
- changing enabled/disabled config within the game

Re: [Rails-devel] [Rails-commits] Branch 'rails2.0' - 4 commits - rails/algorithms rails/common rails/game rails/ui rails/util tools/ListAndFixSavedFiles.java

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

Stefan,

>     changed creation of states to factory method create() only

> -        money = new CashModel(this);
> +        money = CashModel.create(this);

Interesting, but I wonder: what is the benefit?  Or is this just a matter of
personal style?

Erik.

Re: [Rails-devel] Releasing 1.6.1 this weekend?

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

All:
as I have been pretty busy and the recent commits of Erik require branching the master for a
1.6.x release series, the release of 1.6.1 got delayed: Hope do get it done until Monday latest.

The upgrade to OpenSUSE 12.1 today does not help either, as it requires
installing Eclipse afresh (which is not part of the suse repos unfortunately).

Due to the upgrade I also pushed my current local Rails 2.0 branch, which still does not compile,
however it is close (only 32 errors remaining, down from around 600 at top).
So stay tuned for more updates in the not too distant future.

Stefan


-----Ursprüngliche Nachricht-----
Von: "Stefan Frey" <ste...@we...>
Gesendet: Jan 20, 2012 11:59:14 AM
An: "Development list for Rails: an 18xx game" <rai...@li...>
Betreff: [Rails-devel] Releasing 1.6.1 this weekend?

All:
I plan to release 1.6.1. at the end of this weekend, as there are quite a few
of Frederick changes are piling up.
So keep last-minute fixes and changes rolling in ...

My intention is to update the 2.0 branch with my current local repo this or
next weekend latest. Lots of stuff changed, so I hope to present something
soon that is worth of feedback.

Stefan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] GameStatus PlayerReordering consequences..

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

The point is that we don’t have a trigger except through the Observer interface itself.  Perhaps I can set up something that does not just handle the captions but the whole columns.

Another way would be to add indirection in the game engine in a similar way as I have done for the captions: putting the Model objects in arrays and reorder these arrays.  But there the problem is that the models are not kept somewhere centrally.

 

It seems I’ll have to rethink my solution for the captions as well, and generalise it somehow to cover whole columns.  Stay tuned.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Friday, January 27, 2012 11:30 PM
To: Rails Development
Subject: [Rails-devel] GameStatus PlayerReordering consequences..

 

Hm,

 

as far as i can decipher the code :).

 

You are using addField to set the information in the gridpanel and then add an Observer to the datamodel linking it to that information field.

 

Would a possible way to deregister the observer and refill the field/fields once after the playerorder has been changed and add the observers again ? (a "replaceField" method perhaps ?)

 

Sorry but i have the feeling that this is beyond my current understanding :( Nevertheless i'll give it a try :)

 

Regards,

Martin

 

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

An: <Dr....@t-...>, "'Rails Development'" <rai...@li...>

Betreff: RE: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

Datum: Fri, 27 Jan 2012 22:51:11 +0100

 

 

Ah, I must have been under the false impression that only the captions were wrong.  I didn’t really look at the numbers.

Perhaps you can take the captions as an example.  All cells are already variable, so it’s only the view-model relations that somehow need to be reordered.

 

Erik.

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Friday, January 27, 2012 10:23 PM
To: Erik Vos; Rails Development
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

 

Hi Eric,

 

thanks for your help!

 

That takes of course care of the caption, what i doesnt solve is the second part, 

 

Now the player order is shown in the right order but the fields associated with the players remain in the old order. 

 

I'll have a look at that now.

 

Regards,

Martin

 

 

[Rails-devel] GameStatus PlayerReordering consequences..

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

Hm, 

	as far as i can decipher the code :). 

	You are using addField to set the information in the gridpanel and
then add an Observer to the datamodel linking it to that information
field. 

	Would a possible way to deregister the observer and refill the
field/fields once after the playerorder has been changed and add the
observers again ? (a "replaceField" method perhaps ?) 

	Sorry but i have the feeling that this is beyond my current
understanding :( Nevertheless i'll give it a try :) 

	Regards, 

	Martin  

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

	An: <Dr....@t-...>, "'Rails Development'"
<rai...@li...> 

	Betreff: RE: [Rails-devel] Fw: Re:  Push Request : 1880 Code Update
Part II 

	Datum: Fri, 27 Jan 2012 22:51:11 +0100 

	Ah, I must have been under the false impression that only the
captions were wrong.  I didn’t really look at the numbers. 

	Perhaps you can take the captions as an example.  All cells are
already variable, so it’s only the view-model relations that somehow
need to be reordered. 

	Erik. 

	From: Dr....@t-...
[mailto:Dr....@t-...] 
Sent: Friday, January 27, 2012 10:23 PM
To: Erik Vos; Rails Development
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update
Part II   

	Hi Eric, 

	thanks for your help! 

	That takes of course care of the caption, what i doesnt solve is the
second part,  

	Now the player order is shown in the right order but the fields
associated with the players remain in the old order.  

	I'll have a look at that now. 

	Regards, 

	Martin

Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

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

Ah, I must have been under the false impression that only the captions were wrong.  I didn’t really look at the numbers.

Perhaps you can take the captions as an example.  All cells are already variable, so it’s only the view-model relations that somehow need to be reordered.

 

Erik.

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Friday, January 27, 2012 10:23 PM
To: Erik Vos; Rails Development
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

 

Hi Eric,

 

thanks for your help!

 

That takes of course care of the caption, what i doesnt solve is the second part, 

 

Now the player order is shown in the right order but the fields associated with the players remain in the old order. 

 

I'll have a look at that now.

 

Regards,

Martin

 

Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

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

Hi Eric, 

	thanks for your help! 

	That takes of course care of the caption, what i doesnt solve is the
second part,  

	Now the player order is shown in the right order but the fields
associated with the players remain in the old order.  

	I'll have a look at that now. 

	Regards, 

	Martin

Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

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

OK, I have committed code that does the job of reordering player names in the GUI, as far as I have been able to test.

The adaptability of player names is generic, but it is enabled on a per-game basis.  
This enabling is currently hardcoded (see below), but could be turned into an XML game property.
Player reordering is now undoable as well. The UI name updates follow the standard Observer-based Model/ViewObject mechanism that is used for all UI updates.


The commit text:

Player captions made variable to reflect player reordering.

Capability is game-dependent. Setting it is currently hardcoded in GameManager[_1880].setGuiParameters().
The list of players in GameManager is now an ArrayListState.
As ArrayListState does not inherit from ModelObject, a separate StringState[] array had to be created to hold the player names for use in the GUI.
A new Cell superclass for Caption and Field allows Field to get a caption background and also centralises highlighting.


Erik.

---------------------
From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, January 25, 2012 10:02 PM
To: Erik Vos
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

Hi Erik,
 
a number jump to my mind :)
 
Problem 1:
Based on the Fact that the PlayerOrder can change afte the outcome of the StartRound we need to have a flag to switch that order around and let the UI know that it needs to be aware of a new playerorder: Subsequently.
1. The upperPlayerCaption and lowerPlayerCaption need to be updated with the new player order. 
2. the player related fields need to be updated also in new order.
 

Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

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

Done. The only thing needed was to exempt the player names list from reordering.  

This list was in fact only in one place used for other purposes than saving, and that single existing usage could easily be replaced. 

So I could also remove getPlayerNames() from the GameManagerI interface.

 

As a bonus, I noticed, that the UI now shows the *reordered* player names in the UI after reloading .  So that’s a first step in fixing the other problems.

 

Erik.

 

From: Erik Vos [mailto:eri...@xs...] 
Sent: Thursday, January 26, 2012 9:56 PM
To: Dr....@t-...; 'Rails Development'
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

 

Indeed the problem seems to be that the *current* player sequence is saved, instead of the *original* sequence.

When reloading, the game engine replays the game from the start, so the original player names list must be saved.

That should be easy to fix.  

 

Another problem, is that the player list is not a state variable and so reordering is not undoable. But I’ll leave that as is for a while, as Stefan will turn it upside down anyway.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Thursday, January 26, 2012 8:12 PM
To: Erik Vos; Rails Development
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

 

Hi Erik,

 

please find enclosed the savegame.

 

The problem arises fro the fact that in 1880 i "artificially" reorder the players based on the outcome of Startround. The game of course only saves actions and some variables and the load mechanismn cant determine the changed player order. This leads to the fact that the playername array will have the original player as actionstarter "A" while getcurrentplayer() of course returns the new playerorder (in this case "C") as the players-array has been reordered after the startinground and C ist the player with the fewest money thus the first player in the new seat order.

 

How do we want to go here ?

 

If we add the original seat order as additional data to be saved we still have the problem to be solved that the actions up to a specific point in game time (end of Startround) which we currently cant pinpoint (as only actions get saved and restored), are connected to the wrong player.

Should we perhaps create a special action that then can be saved ? and of course must be run automatically ? or manually ?

 

Regards,

Martin

 

Von: "Erik Vos" <eri...@xs...>
An: <Dr....@t-...>
Cc: "Development list for Rails: an 18xx game" <rai...@li...>
Betreff: RE: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II
Datum: Thu, 26 Jan 2012 14:45:07 +0100

Martin,

OK, let's work on these issues together.

1. The simple way out would be to change highlighting only, but I would immediately concede that actually changing the visible player order is much better. So let's aim for that.
However, before making plans, we should have a solution to the next problem as well.

2. Apparently, the player order change has not yet been fully worked out. Can you send me a saved file that doesn't reload, so I can check out why it fails?

3. This is a different matter that we can deal with separately. In any case, it's OK to start with using modal popups, which is much easier. Once that works, it's not a big deal to refactor to use non-modal popups. I can pick up the second part, or all of it if you still don't feel happy about it.

Erik.


From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, January 25, 2012 10:02 PM
To: Erik Vos
Subject: Re: [Rails-devel] Fw: Re: Push Request : 1880 Code Update Part II

Hi Erik,

a number jump to my mind :)

Problem 1:
Based on the Fact that the PlayerOrder can change afte the outcome of the StartRound we need to have a flag to switch that order around and let the UI know that it needs to be aware of a new playerorder: Subsequently.
1. The upperPlayerCaption and lowerPlayerCaption need to be updated with the new player order. 
2. the player related fields need to be updated also in new order.

Currently the player order gets changed, the wrong player is shown as acting but the right player credited with the action. I.e. Player order in Display is A B C D, player c has fewest money after start is now starting player for stock round. 

Player A is highlighted performs an action and result of action is credited to player c in display. (this is right but confusing as player c should have moved in display to first colomn been highlighted and shown as performing the action :))

Problem 2:
The reordering of players causes the game to reject any save game after the initial Startround. Player x cant perform that action...

Problem 3:

The StartCompany-mechanismn is now for StartroundWindow two actions subsequently (Because the share size of the BCR president share is fixed..)
For each other company its three actions in order: a) Determine the startprice/startingorderposition
b) Determine the size of the presidents share -20/30/40%
c) Determine the BuildingRight based on restrictions from the presidents share (40& Shares can only have Phase A or B or C or D, 30% can have 2 Phases and 20% can have 3 Phases (A+B+C, B+C+D)

This in connection with the radiobuttoncode is beyond my skills yet :)

Those are my most urgent problems where the wall is to stubborn to give way to my head !

Regards,
Martin

P.s. your comments where helpful and the right way to show me the way around, i can take positive criticismn :)