rails-devel — List for discussion of Rails development

Re: [Rails-devel] Git repository is now available.

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

Bill -

Yup. That's a fairly normal workflow for Git.

Rebasing your local commit history for public consumption is one of
the nicer things Git supports. However, because it does change the
repository's history, it's a bit tricky to get correct.

The most important detail is that once changes are pushed to the
public repository, they shouldn't be changed. See the "recovering from
an upstream rebase" portion of the 'git rebase' man page:
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

---Brett.



On Sun, Jul 17, 2011 at 11:07 PM, Bill Rosgen <ro...@gm...> wrote:
> I'm somewhat new to Git and so have a workflow question.  Let me know if the following seems reasonable, especially step 3:
>
> 1. Alice wishes to add a new feature (say, support for 1848).  She creates a local branch (1848-dev) and begins work.
>
> 2. Alice makes several commits to her local branch while implementing this feature.  In the mean-time, the master branch will have also changed.
>
> 3. Alice rebases her local branch on top of the current state of the master branch and fixes any conflicts.  As she does this she squashes all of her local commits into one commit as the rest of the developers probably don't want or need all of her committed but only partially implemented versions of the feature.
>
> 4. Now that her local branch is one commit away from the current master, Alice creates and sends a patch that implements the new feature.
>
> (I'm still working on 1848, but it's quite far being from done: I haven't sent anything, as I don't know how useful it is to have another partially implemented (unplayable) game.)
>
> Bill
>
> On 2011-07-18, at 3:19 , brett lentz wrote:
>
>> I've migrated all of the commits up to r1614 from SVN into the Git
>> repository on SF.net.
>>
>> Currently, none of the tags have been migrated due to differences in
>> how SVN and Git handle tags. I'll be pushing the tags up as soon as I
>> have them ready.
>>
>> Important note for committers:
>>
>> Please set up your .gitconfig to include your name and e-mail address
>> for all future commits.
>>
>> During the migration, you'll note I've converted all existing commits
>> to use this information. To have the tree remain consistent, you'll
>> need to follow suit.
>>
>> ---Brett.
>>
>>
>>
>> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
>>> That would be great.  Thanks.
>>> Erik.
>>>
>>>> -----Original Message-----
>>>> From: brett lentz [mailto:bre...@gm...]
>>>> Sent: Monday, July 11, 2011 9:45 PM
>>>> To: Development list for Rails: an 18xx game
>>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>>>
>>>> I'll work on it this week.  This coming weekend should be a good target for
>>>> the cutover.
>>>>
>>>> ---Brett.
>>>>
>>>>
>>>>
>>>> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
>>>>> OK, it seems we are ready then for the switchover.
>>>>>
>>>>> Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
>>>>> I suppose it's better to create a fresh new repository than to do a
>>>>> massive update to get the current old one up to date.
>>>>>
>>>>> Erik.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Phil Davies [mailto:de...@gm...]
>>>>>> Sent: Monday, July 11, 2011 10:56 AM
>>>>>> To: Development list for Rails: an 18xx game
>>>>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>>>>>
>>>>>> As far as I'm concerned it's really Brett, Erik and Stefan's decision
>>>>> being the
>>>>>> primary contributors to the project.  IntelliJ has a Git plugin so
>>>>>> I'm
>>>>> sure I'll
>>>>>> work it out :)
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>>>>>>> Erik & Brett,
>>>>>>> given that you both had some long-time hands-on-experience with
>>>>>>> Maven (compared to my third-party recommendation and a short
>>>>>>> try-out) I agree to stay with the current setup.
>>>>>>> I had not tested EGit/JGit before, thus I considered them as
>>>>>>> competing products similar to the svn-support in eclipse ;-) Stefan
>>>>>>>
>>>>>>> On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>>>>>>>> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Stefan Frey [mailto:ste...@we...]
>>>>>>>>>> Sent: Sunday, July 10, 2011 2:42 PM
>>>>>>>>>> To: Development list for Rails: an 18xx game
>>>>>>>>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>>>>>>>>>
>>>>>>>>>> Erik & Brett,
>>>>>>>>>> I am up for that move. Do you recommend JGit or Egit?
>>>>>>>>>
>>>>>>>>> AFAIK you need both (in Eclipse).
>>>>>>>>
>>>>>>>> Correct.
>>>>>>>>
>>>>>>>> JGit is the java git implementation.
>>>>>>>> EGit is the eclipse plugin built on top of JGit.
>>>>>>>>
>>>>>>>>>> I am wondering if you would consider to move to a maven  build
>>>>>>>>>> at the same time. Ideally by changing to the maven recommended
>>>>>>>>>> repo
>>>>>> layout.
>>>>>>>>>
>>>>>>>>> Dunno. Brett is handling the builds (I only run either from
>>>>>>>>> Eclipse Run or from the published Rails jars).
>>>>>>>>>
>>>>>>>>> I hardly know anything about Maven. In the past I have been
>>>>>>>>> half-involved with some (old) projects that used Maven, and
>>>>>>>>> perhaps
>>>>>> some other stuff.
>>>>>>>>> What I remember about these projects was the ubiquitous presence
>>>>>>>>> of pom.xml files that did not mean anything to me (I wasn't
>>>>>>>>> really interested either - it worked). So I'm blank.
>>>>>>>>
>>>>>>>> I deal with Maven at my day job, and I'm not a fan. Perhaps as
>>>>>>>> Maven
>>>>>>>> 3 matures, it will improve in crucial areas. Right now, I really
>>>>>>>> dislike the way it handles dependency resolution, among other things.
>>>>>>>>
>>>>>>>>> Perhaps we'll better restrict ourselves to one major step at a time?
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>>> One thing on our Git repo that I have struggled with yesterday
>>>>>>>>> is that it seems to require that the .git directory would exist
>>>>>>>>> at the same level as all project directories (game, tile, data
>>>>>>>>> etc.).  I was trying to get these directories below a src
>>>>>>>>> directory on the same level as .git (under the project root),
>>>>>>>>> but failed  to get there. Not really a problem, but perhaps
>>>> noteworthy.
>>>>>>>>>
>>>>>>>>> Erik.
>>>>>>>>
>>>>>>>> ---Brett.
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> ---
>>>>>>>> ------
>>>>>>>> --- All of the data generated in your IT infrastructure is
>>>>>>>> seriously valuable. Why? It contains a definitive record of
>>>>>>>> application performance, security threats, fraudulent activity,
>>>>>>>> and more. Splunk takes this data and makes sense of it. IT sense. And
>>>> common sense.
>>>>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>>>>> _______________________________________________
>>>>>>>> Rails-devel mailing list
>>>>>>>> Rai...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>>>
>>>>>>> -------------------------------------------------------------------
>>>>>>> ---
>>>>>>> -------- All of the data generated in your IT infrastructure is
>>>>>>> seriously valuable.
>>>>>>> Why? It contains a definitive record of application performance,
>>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>>>> _______________________________________________
>>>>>>> Rails-devel mailing list
>>>>>>> Rai...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> ------
>>>>> --
>>>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>>>> Why? It contains a definitive record of application performance,
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>>> _______________________________________________
>>>>>> Rails-devel mailing list
>>>>>> Rai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> -------- All of the data generated in your IT infrastructure is
>>>>> seriously valuable.
>>>>> Why? It contains a definitive record of application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>> Why? It contains a definitive record of application performance, security
>>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> AppSumo Presents a FREE Video for the SourceForge Community by Eric
>> Ries, the creator of the Lean Startup Methodology on "Lean Startup
>> Secrets Revealed." This video shows you how to validate your ideas,
>> optimize your ideas and identify your business strategy.
>> http://p.sf.net/sfu/appsumosfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Git repository is now available.

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

Oops, serves me right for not reading all mails to the list thoroughly :$

On 18 July 2011 13:06, Stefan Frey <ste...@we...> wrote:
> Phil:
> that is correct, however not related to the new git repository.
>
> See my mail below from 9th of July...
> Stefan
>
> Erik or Brett:
> On testing I realized that currently for some games/variants a new game cannot
> be started:
>
> 1830 coalfields does not work
> (Null pointer exception in Game class),
> however 1830 base does work.
>
> 1889 does not work
> (Configruation error: Invalid quantity 0 for train cert type 6 in
> TrainCertificateClass).
>
> 1856, 18EU seems to work.
>
> However loading either an older 1830 coalfields or 1889 save file still works.
>
> Another strange thing:
> The  Available Games dropdown shows next to each game instead of the game
> status the same label "Notes".
>
> I am pretty sure that neither of this was caused by my work, do you have any
> ideas what happened there?
>
> Stefan
>
>
> On Monday, July 18, 2011 01:50:44 pm Phil Davies wrote:
>> Something strange in the version checked out from Git.  On the
>> available games dialogue at startup, each game just ahs the word
>> 'Notes' next to it, rather than the previous designation of 'playable,
>> unplayable' etc.
>>
>> On 18 July 2011 10:10, Erik Vos <eri...@xs...> wrote:
>> > OK, I have imported the new repository via Eclipse, and all seems well.
>> > Later this week I'll try to resume bug fixing and other useful work.
>> >
>> > Erik.
>> >
>> >> -----Original Message-----
>> >> From: brett lentz [mailto:bre...@gm...]
>> >> Sent: Sunday, July 17, 2011 9:20 PM
>> >> To: Development list for Rails: an 18xx game
>> >> Subject: [Rails-devel] Git repository is now available.
>> >>
>> >> I've migrated all of the commits up to r1614 from SVN into the Git
>> >> repository on SF.net.
>> >>
>> >> Currently, none of the tags have been migrated due to differences in how
>> >> SVN and Git handle tags. I'll be pushing the tags up as soon as I have
>> >> them ready.
>> >>
>> >> Important note for committers:
>> >>
>> >> Please set up your .gitconfig to include your name and e-mail address
>> >> for all future commits.
>> >>
>> >> During the migration, you'll note I've converted all existing commits to
>> >> use this information. To have the tree remain consistent, you'll need
>> >> to follow suit.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
>> >> > That would be great.  Thanks.
>> >> > Erik.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: brett lentz [mailto:bre...@gm...]
>> >> >> Sent: Monday, July 11, 2011 9:45 PM
>> >> >> To: Development list for Rails: an 18xx game
>> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >>
>> >> >> I'll work on it this week.  This coming weekend should be a good
>> >> >> target for the cutover.
>> >> >>
>> >> >> ---Brett.
>> >> >>
>> >> >> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
>> >> >> > OK, it seems we are ready then for the switchover.
>> >> >> >
>> >> >> > Brett, when do you think you can have rebuilt the Git repo at
>> >>
>> >> Sourceforge?
>> >>
>> >> >> > I suppose it's better to create a fresh new repository than to do a
>> >> >> > massive update to get the current old one up to date.
>> >> >> >
>> >> >> > Erik.
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Phil Davies [mailto:de...@gm...]
>> >> >> >> Sent: Monday, July 11, 2011 10:56 AM
>> >> >> >> To: Development list for Rails: an 18xx game
>> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >> >>
>> >> >> >> As far as I'm concerned it's really Brett, Erik and Stefan's
>> >> >> >> decision
>> >> >> >
>> >> >> > being the
>> >> >> >
>> >> >> >> primary contributors to the project.  IntelliJ has a Git plugin so
>> >> >> >> I'm
>> >> >> >
>> >> >> > sure I'll
>> >> >> >
>> >> >> >> work it out :)
>> >> >> >>
>> >> >> >> Phil
>> >> >> >>
>> >> >> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>> >> >> >> > Erik & Brett,
>> >> >> >> > given that you both had some long-time hands-on-experience with
>> >> >> >> > Maven (compared to my third-party recommendation and a short
>> >> >> >> > try-out) I agree to stay with the current setup.
>> >> >> >> > I had not tested EGit/JGit before, thus I considered them as
>> >> >> >> > competing products similar to the svn-support in eclipse ;-)
>> >> >> >> > Stefan
>> >> >> >> >
>> >> >> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>> >> >> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...>
>> >>
>> >> wrote:
>> >> >> >> >> >> -----Original Message-----
>> >> >> >> >> >> From: Stefan Frey [mailto:ste...@we...]
>> >> >> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
>> >> >> >> >> >> To: Development list for Rails: an 18xx game
>> >> >> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >> >> >> >>
>> >> >> >> >> >> Erik & Brett,
>> >> >> >> >> >> I am up for that move. Do you recommend JGit or Egit?
>> >> >> >> >> >
>> >> >> >> >> > AFAIK you need both (in Eclipse).
>> >> >> >> >>
>> >> >> >> >> Correct.
>> >> >> >> >>
>> >> >> >> >> JGit is the java git implementation.
>> >> >> >> >> EGit is the eclipse plugin built on top of JGit.
>> >> >> >> >>
>> >> >> >> >> >> I am wondering if you would consider to move to a maven
>> >> >> >> >> >> build at the same time. Ideally by changing to the maven
>> >> >> >> >> >> recommended repo
>> >> >> >>
>> >> >> >> layout.
>> >> >> >>
>> >> >> >> >> > Dunno. Brett is handling the builds (I only run either from
>> >> >> >> >> > Eclipse Run or from the published Rails jars).
>> >> >> >> >> >
>> >> >> >> >> > I hardly know anything about Maven. In the past I have been
>> >> >> >> >> > half-involved with some (old) projects that used Maven, and
>> >> >> >> >> > perhaps
>> >> >> >>
>> >> >> >> some other stuff.
>> >> >> >>
>> >> >> >> >> > What I remember about these projects was the ubiquitous
>> >> >> >> >> > presence of pom.xml files that did not mean anything to me (I
>> >> >> >> >> > wasn't really interested either - it worked). So I'm blank.
>> >> >> >> >>
>> >> >> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
>> >> >> >> >> Maven
>> >> >> >> >> 3 matures, it will improve in crucial areas. Right now, I
>> >> >> >> >> really dislike the way it handles dependency resolution, among
>> >>
>> >> other things.
>> >>
>> >> >> >> >> > Perhaps we'll better restrict ourselves to one major step at
>> >> >> >> >> > a
>> >>
>> >> time?
>> >>
>> >> >> >> >> Agreed.
>> >> >> >> >>
>> >> >> >> >> > One thing on our Git repo that I have struggled with
>> >> >> >> >> > yesterday is that it seems to require that the .git directory
>> >> >> >> >> > would exist at the same level as all project directories
>> >> >> >> >> > (game, tile, data etc.).  I was trying to get these
>> >> >> >> >> > directories below a src directory on the same level as .git
>> >> >> >> >> > (under the project root), but failed  to get there. Not
>> >> >> >> >> > really a problem, but perhaps
>> >> >>
>> >> >> noteworthy.
>> >> >>
>> >> >> >> >> > Erik.
>> >> >> >> >>
>> >> >> >> >> ---Brett.
>> >> >> >> >>
>> >> >> >> >> ---------------------------------------------------------------
>> >> >> >> >> ---
>> >> >> >> >> ---
>> >> >> >> >> ------
>> >> >> >> >> --- All of the data generated in your IT infrastructure is
>> >> >> >> >> seriously valuable. Why? It contains a definitive record of
>> >> >> >> >> application performance, security threats, fraudulent activity,
>> >> >> >> >> and more. Splunk takes this data and makes sense of it. IT
>> >> >> >> >> sense. And
>> >> >>
>> >> >> common sense.
>> >> >>
>> >> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> >> >> _______________________________________________
>> >> >> >> >> Rails-devel mailing list
>> >> >> >> >> Rai...@li...
>> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >> >> >
>> >> >> >> > ----------------------------------------------------------------
>> >> >> >> > ---
>> >> >> >> > ---
>> >> >> >> > -------- All of the data generated in your IT infrastructure is
>> >> >> >> > seriously valuable.
>> >> >> >> > Why? It contains a definitive record of application performance,
>> >> >> >> > security threats, fraudulent activity, and more. Splunk takes
>> >> >> >> > this data and makes sense of it. IT sense. And common sense.
>> >> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> >> > _______________________________________________
>> >> >> >> > Rails-devel mailing list
>> >> >> >> > Rai...@li...
>> >> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >> >
>> >> >> > -------------------------------------------------------------------
>> >> >> > ---
>> >> >> > ------
>> >> >> > --
>> >> >> >
>> >> >> >> All of the data generated in your IT infrastructure is seriously
>> >> >> >> valuable. Why? It contains a definitive record of application
>> >> >> >> performance, security threats, fraudulent activity, and more.
>> >> >> >> Splunk takes this data and makes sense of it. IT sense. And
>> >> >> >> common sense.
>> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> >> _______________________________________________
>> >> >> >> Rails-devel mailing list
>> >> >> >> Rai...@li...
>> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >> >
>> >> >> > -------------------------------------------------------------------
>> >> >> > ---
>> >> >> > -------- All of the data generated in your IT infrastructure is
>> >> >> > seriously valuable.
>> >> >> > Why? It contains a definitive record of application performance,
>> >> >> > security threats, fraudulent activity, and more. Splunk takes this
>> >> >> > data and makes sense of it. IT sense. And common sense.
>> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> > _______________________________________________
>> >> >> > Rails-devel mailing list
>> >> >> > Rai...@li...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> --------- All of the data generated in your IT infrastructure is
>> >> >> seriously valuable.
>> >> >> Why? It contains a definitive record of application performance,
>> >> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> >> data and makes sense of it. IT sense. And common sense.
>> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> _______________________________________________
>> >> >> Rails-devel mailing list
>> >> >> Rai...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >> > ----------------------------------------------------------------------
>> >> > -------- All of the data generated in your IT infrastructure is
>> >> > seriously valuable.
>> >> > Why? It contains a definitive record of application performance,
>> >> > security threats, fraudulent activity, and more. Splunk takes this
>> >> > data and makes sense of it. IT sense. And common sense.
>> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> > _______________________________________________
>> >> > Rails-devel mailing list
>> >> > Rai...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >> ------------------------------------------------------------------------
>> >> ------ AppSumo Presents a FREE Video for the SourceForge Community by
>> >> Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup
>> >> Secrets Revealed." This video shows you how to validate your ideas,
>> >> optimize your ideas and identify your business strategy.
>> >> http://p.sf.net/sfu/appsumosfdev2dev
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > -------------------------------------------------------------------------
>> > ----- AppSumo Presents a FREE Video for the SourceForge Community by Eric
>> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
>> > Secrets Revealed." This video shows you how to validate your ideas,
>> > optimize your ideas and identify your business strategy.
>> > http://p.sf.net/sfu/appsumosfdev2dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
>> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
>> Revealed." This video shows you how to validate your ideas, optimize your
>> ideas and identify your business strategy.
>> http://p.sf.net/sfu/appsumosfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Git repository is now available.

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

Phil:
that is correct, however not related to the new git repository.

See my mail below from 9th of July...
Stefan

Erik or Brett:
On testing I realized that currently for some games/variants a new game cannot 
be started:

1830 coalfields does not work 
(Null pointer exception in Game class), 
however 1830 base does work.

1889 does not work
(Configruation error: Invalid quantity 0 for train cert type 6 in 
TrainCertificateClass).

1856, 18EU seems to work.

However loading either an older 1830 coalfields or 1889 save file still works.

Another strange thing:
The  Available Games dropdown shows next to each game instead of the game 
status the same label "Notes".

I am pretty sure that neither of this was caused by my work, do you have any
ideas what happened there?

Stefan


On Monday, July 18, 2011 01:50:44 pm Phil Davies wrote:
> Something strange in the version checked out from Git.  On the
> available games dialogue at startup, each game just ahs the word
> 'Notes' next to it, rather than the previous designation of 'playable,
> unplayable' etc.
> 
> On 18 July 2011 10:10, Erik Vos <eri...@xs...> wrote:
> > OK, I have imported the new repository via Eclipse, and all seems well.
> > Later this week I'll try to resume bug fixing and other useful work.
> > 
> > Erik.
> > 
> >> -----Original Message-----
> >> From: brett lentz [mailto:bre...@gm...]
> >> Sent: Sunday, July 17, 2011 9:20 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: [Rails-devel] Git repository is now available.
> >> 
> >> I've migrated all of the commits up to r1614 from SVN into the Git
> >> repository on SF.net.
> >> 
> >> Currently, none of the tags have been migrated due to differences in how
> >> SVN and Git handle tags. I'll be pushing the tags up as soon as I have
> >> them ready.
> >> 
> >> Important note for committers:
> >> 
> >> Please set up your .gitconfig to include your name and e-mail address
> >> for all future commits.
> >> 
> >> During the migration, you'll note I've converted all existing commits to
> >> use this information. To have the tree remain consistent, you'll need
> >> to follow suit.
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
> >> > That would be great.  Thanks.
> >> > Erik.
> >> > 
> >> >> -----Original Message-----
> >> >> From: brett lentz [mailto:bre...@gm...]
> >> >> Sent: Monday, July 11, 2011 9:45 PM
> >> >> To: Development list for Rails: an 18xx game
> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >> 
> >> >> I'll work on it this week.  This coming weekend should be a good
> >> >> target for the cutover.
> >> >> 
> >> >> ---Brett.
> >> >> 
> >> >> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
> >> >> > OK, it seems we are ready then for the switchover.
> >> >> > 
> >> >> > Brett, when do you think you can have rebuilt the Git repo at
> >> 
> >> Sourceforge?
> >> 
> >> >> > I suppose it's better to create a fresh new repository than to do a
> >> >> > massive update to get the current old one up to date.
> >> >> > 
> >> >> > Erik.
> >> >> > 
> >> >> >> -----Original Message-----
> >> >> >> From: Phil Davies [mailto:de...@gm...]
> >> >> >> Sent: Monday, July 11, 2011 10:56 AM
> >> >> >> To: Development list for Rails: an 18xx game
> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >> >> 
> >> >> >> As far as I'm concerned it's really Brett, Erik and Stefan's
> >> >> >> decision
> >> >> > 
> >> >> > being the
> >> >> > 
> >> >> >> primary contributors to the project.  IntelliJ has a Git plugin so
> >> >> >> I'm
> >> >> > 
> >> >> > sure I'll
> >> >> > 
> >> >> >> work it out :)
> >> >> >> 
> >> >> >> Phil
> >> >> >> 
> >> >> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
> >> >> >> > Erik & Brett,
> >> >> >> > given that you both had some long-time hands-on-experience with
> >> >> >> > Maven (compared to my third-party recommendation and a short
> >> >> >> > try-out) I agree to stay with the current setup.
> >> >> >> > I had not tested EGit/JGit before, thus I considered them as
> >> >> >> > competing products similar to the svn-support in eclipse ;-)
> >> >> >> > Stefan
> >> >> >> > 
> >> >> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
> >> >> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...>
> >> 
> >> wrote:
> >> >> >> >> >> -----Original Message-----
> >> >> >> >> >> From: Stefan Frey [mailto:ste...@we...]
> >> >> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
> >> >> >> >> >> To: Development list for Rails: an 18xx game
> >> >> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >> >> >> >> 
> >> >> >> >> >> Erik & Brett,
> >> >> >> >> >> I am up for that move. Do you recommend JGit or Egit?
> >> >> >> >> > 
> >> >> >> >> > AFAIK you need both (in Eclipse).
> >> >> >> >> 
> >> >> >> >> Correct.
> >> >> >> >> 
> >> >> >> >> JGit is the java git implementation.
> >> >> >> >> EGit is the eclipse plugin built on top of JGit.
> >> >> >> >> 
> >> >> >> >> >> I am wondering if you would consider to move to a maven
> >> >> >> >> >> build at the same time. Ideally by changing to the maven
> >> >> >> >> >> recommended repo
> >> >> >> 
> >> >> >> layout.
> >> >> >> 
> >> >> >> >> > Dunno. Brett is handling the builds (I only run either from
> >> >> >> >> > Eclipse Run or from the published Rails jars).
> >> >> >> >> > 
> >> >> >> >> > I hardly know anything about Maven. In the past I have been
> >> >> >> >> > half-involved with some (old) projects that used Maven, and
> >> >> >> >> > perhaps
> >> >> >> 
> >> >> >> some other stuff.
> >> >> >> 
> >> >> >> >> > What I remember about these projects was the ubiquitous
> >> >> >> >> > presence of pom.xml files that did not mean anything to me (I
> >> >> >> >> > wasn't really interested either - it worked). So I'm blank.
> >> >> >> >> 
> >> >> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
> >> >> >> >> Maven
> >> >> >> >> 3 matures, it will improve in crucial areas. Right now, I
> >> >> >> >> really dislike the way it handles dependency resolution, among
> >> 
> >> other things.
> >> 
> >> >> >> >> > Perhaps we'll better restrict ourselves to one major step at
> >> >> >> >> > a
> >> 
> >> time?
> >> 
> >> >> >> >> Agreed.
> >> >> >> >> 
> >> >> >> >> > One thing on our Git repo that I have struggled with
> >> >> >> >> > yesterday is that it seems to require that the .git directory
> >> >> >> >> > would exist at the same level as all project directories
> >> >> >> >> > (game, tile, data etc.).  I was trying to get these
> >> >> >> >> > directories below a src directory on the same level as .git
> >> >> >> >> > (under the project root), but failed  to get there. Not
> >> >> >> >> > really a problem, but perhaps
> >> >> 
> >> >> noteworthy.
> >> >> 
> >> >> >> >> > Erik.
> >> >> >> >> 
> >> >> >> >> ---Brett.
> >> >> >> >> 
> >> >> >> >> ---------------------------------------------------------------
> >> >> >> >> ---
> >> >> >> >> ---
> >> >> >> >> ------
> >> >> >> >> --- All of the data generated in your IT infrastructure is
> >> >> >> >> seriously valuable. Why? It contains a definitive record of
> >> >> >> >> application performance, security threats, fraudulent activity,
> >> >> >> >> and more. Splunk takes this data and makes sense of it. IT
> >> >> >> >> sense. And
> >> >> 
> >> >> common sense.
> >> >> 
> >> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> >> >> _______________________________________________
> >> >> >> >> Rails-devel mailing list
> >> >> >> >> Rai...@li...
> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> >> > 
> >> >> >> > ----------------------------------------------------------------
> >> >> >> > ---
> >> >> >> > ---
> >> >> >> > -------- All of the data generated in your IT infrastructure is
> >> >> >> > seriously valuable.
> >> >> >> > Why? It contains a definitive record of application performance,
> >> >> >> > security threats, fraudulent activity, and more. Splunk takes
> >> >> >> > this data and makes sense of it. IT sense. And common sense.
> >> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> >> >> > _______________________________________________
> >> >> >> > Rails-devel mailing list
> >> >> >> > Rai...@li...
> >> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> > 
> >> >> > -------------------------------------------------------------------
> >> >> > ---
> >> >> > ------
> >> >> > --
> >> >> > 
> >> >> >> All of the data generated in your IT infrastructure is seriously
> >> >> >> valuable. Why? It contains a definitive record of application
> >> >> >> performance, security threats, fraudulent activity, and more.
> >> >> >> Splunk takes this data and makes sense of it. IT sense. And
> >> >> >> common sense.
> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> >> _______________________________________________
> >> >> >> Rails-devel mailing list
> >> >> >> Rai...@li...
> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> > 
> >> >> > -------------------------------------------------------------------
> >> >> > ---
> >> >> > -------- All of the data generated in your IT infrastructure is
> >> >> > seriously valuable.
> >> >> > Why? It contains a definitive record of application performance,
> >> >> > security threats, fraudulent activity, and more. Splunk takes this
> >> >> > data and makes sense of it. IT sense. And common sense.
> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> >> > _______________________________________________
> >> >> > Rails-devel mailing list
> >> >> > Rai...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> --------- All of the data generated in your IT infrastructure is
> >> >> seriously valuable.
> >> >> Why? It contains a definitive record of application performance,
> >> >> security threats, fraudulent activity, and more. Splunk takes this
> >> >> data and makes sense of it. IT sense. And common sense.
> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> > 
> >> > ----------------------------------------------------------------------
> >> > -------- All of the data generated in your IT infrastructure is
> >> > seriously valuable.
> >> > Why? It contains a definitive record of application performance,
> >> > security threats, fraudulent activity, and more. Splunk takes this
> >> > data and makes sense of it. IT sense. And common sense.
> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> ------ AppSumo Presents a FREE Video for the SourceForge Community by
> >> Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup
> >> Secrets Revealed." This video shows you how to validate your ideas,
> >> optimize your ideas and identify your business strategy.
> >> http://p.sf.net/sfu/appsumosfdev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Git repository is now available.

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

Something strange in the version checked out from Git.  On the
available games dialogue at startup, each game just ahs the word
'Notes' next to it, rather than the previous designation of 'playable,
unplayable' etc.

On 18 July 2011 10:10, Erik Vos <eri...@xs...> wrote:
> OK, I have imported the new repository via Eclipse, and all seems well.
> Later this week I'll try to resume bug fixing and other useful work.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Sunday, July 17, 2011 9:20 PM
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] Git repository is now available.
>>
>> I've migrated all of the commits up to r1614 from SVN into the Git repository
>> on SF.net.
>>
>> Currently, none of the tags have been migrated due to differences in how
>> SVN and Git handle tags. I'll be pushing the tags up as soon as I have them
>> ready.
>>
>> Important note for committers:
>>
>> Please set up your .gitconfig to include your name and e-mail address for all
>> future commits.
>>
>> During the migration, you'll note I've converted all existing commits to use
>> this information. To have the tree remain consistent, you'll need to follow
>> suit.
>>
>> ---Brett.
>>
>>
>>
>> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
>> > That would be great.  Thanks.
>> > Erik.
>> >
>> >> -----Original Message-----
>> >> From: brett lentz [mailto:bre...@gm...]
>> >> Sent: Monday, July 11, 2011 9:45 PM
>> >> To: Development list for Rails: an 18xx game
>> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >>
>> >> I'll work on it this week.  This coming weekend should be a good
>> >> target for the cutover.
>> >>
>> >> ---Brett.
>> >>
>> >>
>> >>
>> >> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
>> >> > OK, it seems we are ready then for the switchover.
>> >> >
>> >> > Brett, when do you think you can have rebuilt the Git repo at
>> Sourceforge?
>> >> > I suppose it's better to create a fresh new repository than to do a
>> >> > massive update to get the current old one up to date.
>> >> >
>> >> > Erik.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Phil Davies [mailto:de...@gm...]
>> >> >> Sent: Monday, July 11, 2011 10:56 AM
>> >> >> To: Development list for Rails: an 18xx game
>> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >>
>> >> >> As far as I'm concerned it's really Brett, Erik and Stefan's
>> >> >> decision
>> >> > being the
>> >> >> primary contributors to the project.  IntelliJ has a Git plugin so
>> >> >> I'm
>> >> > sure I'll
>> >> >> work it out :)
>> >> >>
>> >> >> Phil
>> >> >>
>> >> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>> >> >> > Erik & Brett,
>> >> >> > given that you both had some long-time hands-on-experience with
>> >> >> > Maven (compared to my third-party recommendation and a short
>> >> >> > try-out) I agree to stay with the current setup.
>> >> >> > I had not tested EGit/JGit before, thus I considered them as
>> >> >> > competing products similar to the svn-support in eclipse ;-)
>> >> >> > Stefan
>> >> >> >
>> >> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>> >> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...>
>> wrote:
>> >> >> >> >> -----Original Message-----
>> >> >> >> >> From: Stefan Frey [mailto:ste...@we...]
>> >> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
>> >> >> >> >> To: Development list for Rails: an 18xx game
>> >> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >> >> >>
>> >> >> >> >> Erik & Brett,
>> >> >> >> >> I am up for that move. Do you recommend JGit or Egit?
>> >> >> >> >
>> >> >> >> > AFAIK you need both (in Eclipse).
>> >> >> >>
>> >> >> >> Correct.
>> >> >> >>
>> >> >> >> JGit is the java git implementation.
>> >> >> >> EGit is the eclipse plugin built on top of JGit.
>> >> >> >>
>> >> >> >> >> I am wondering if you would consider to move to a maven
>> >> >> >> >> build at the same time. Ideally by changing to the maven
>> >> >> >> >> recommended repo
>> >> >> layout.
>> >> >> >> >
>> >> >> >> > Dunno. Brett is handling the builds (I only run either from
>> >> >> >> > Eclipse Run or from the published Rails jars).
>> >> >> >> >
>> >> >> >> > I hardly know anything about Maven. In the past I have been
>> >> >> >> > half-involved with some (old) projects that used Maven, and
>> >> >> >> > perhaps
>> >> >> some other stuff.
>> >> >> >> > What I remember about these projects was the ubiquitous
>> >> >> >> > presence of pom.xml files that did not mean anything to me (I
>> >> >> >> > wasn't really interested either - it worked). So I'm blank.
>> >> >> >>
>> >> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
>> >> >> >> Maven
>> >> >> >> 3 matures, it will improve in crucial areas. Right now, I
>> >> >> >> really dislike the way it handles dependency resolution, among
>> other things.
>> >> >> >>
>> >> >> >> > Perhaps we'll better restrict ourselves to one major step at a
>> time?
>> >> >> >>
>> >> >> >> Agreed.
>> >> >> >>
>> >> >> >> > One thing on our Git repo that I have struggled with
>> >> >> >> > yesterday is that it seems to require that the .git directory
>> >> >> >> > would exist at the same level as all project directories
>> >> >> >> > (game, tile, data etc.).  I was trying to get these
>> >> >> >> > directories below a src directory on the same level as .git
>> >> >> >> > (under the project root), but failed  to get there. Not
>> >> >> >> > really a problem, but perhaps
>> >> noteworthy.
>> >> >> >> >
>> >> >> >> > Erik.
>> >> >> >>
>> >> >> >> ---Brett.
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ---
>> >> >> >> ---
>> >> >> >> ------
>> >> >> >> --- All of the data generated in your IT infrastructure is
>> >> >> >> seriously valuable. Why? It contains a definitive record of
>> >> >> >> application performance, security threats, fraudulent activity,
>> >> >> >> and more. Splunk takes this data and makes sense of it. IT
>> >> >> >> sense. And
>> >> common sense.
>> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> >> _______________________________________________
>> >> >> >> Rails-devel mailing list
>> >> >> >> Rai...@li...
>> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >> >
>> >> >> > ----------------------------------------------------------------
>> >> >> > ---
>> >> >> > ---
>> >> >> > -------- All of the data generated in your IT infrastructure is
>> >> >> > seriously valuable.
>> >> >> > Why? It contains a definitive record of application performance,
>> >> >> > security threats, fraudulent activity, and more. Splunk takes
>> >> >> > this data and makes sense of it. IT sense. And common sense.
>> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> > _______________________________________________
>> >> >> > Rails-devel mailing list
>> >> >> > Rai...@li...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >> >
>> >> >>
>> >> >>
>> >> > -------------------------------------------------------------------
>> >> > ---
>> >> > ------
>> >> > --
>> >> >> All of the data generated in your IT infrastructure is seriously valuable.
>> >> >> Why? It contains a definitive record of application performance,
>> >> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> >> data and makes sense of it. IT sense. And common sense.
>> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> _______________________________________________
>> >> >> Rails-devel mailing list
>> >> >> Rai...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------
>> >> > ---
>> >> > -------- All of the data generated in your IT infrastructure is
>> >> > seriously valuable.
>> >> > Why? It contains a definitive record of application performance,
>> >> > security threats, fraudulent activity, and more. Splunk takes this
>> >> > data and makes sense of it. IT sense. And common sense.
>> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> > _______________________________________________
>> >> > Rails-devel mailing list
>> >> > Rai...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> --------- All of the data generated in your IT infrastructure is
>> >> seriously valuable.
>> >> Why? It contains a definitive record of application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> > ----------------------------------------------------------------------
>> > -------- All of the data generated in your IT infrastructure is
>> > seriously valuable.
>> > Why? It contains a definitive record of application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>> ------------------------------------------------------------------------------
>> AppSumo Presents a FREE Video for the SourceForge Community by Eric
>> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
>> Revealed." This video shows you how to validate your ideas, optimize your
>> ideas and identify your business strategy.
>> http://p.sf.net/sfu/appsumosfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Git repository is now available.

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

OK, I have imported the new repository via Eclipse, and all seems well.
Later this week I'll try to resume bug fixing and other useful work. 

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Sunday, July 17, 2011 9:20 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Git repository is now available.
> 
> I've migrated all of the commits up to r1614 from SVN into the Git repository
> on SF.net.
> 
> Currently, none of the tags have been migrated due to differences in how
> SVN and Git handle tags. I'll be pushing the tags up as soon as I have them
> ready.
> 
> Important note for committers:
> 
> Please set up your .gitconfig to include your name and e-mail address for all
> future commits.
> 
> During the migration, you'll note I've converted all existing commits to use
> this information. To have the tree remain consistent, you'll need to follow
> suit.
> 
> ---Brett.
> 
> 
> 
> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
> > That would be great.  Thanks.
> > Erik.
> >
> >> -----Original Message-----
> >> From: brett lentz [mailto:bre...@gm...]
> >> Sent: Monday, July 11, 2011 9:45 PM
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >>
> >> I'll work on it this week.  This coming weekend should be a good
> >> target for the cutover.
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
> >> > OK, it seems we are ready then for the switchover.
> >> >
> >> > Brett, when do you think you can have rebuilt the Git repo at
> Sourceforge?
> >> > I suppose it's better to create a fresh new repository than to do a
> >> > massive update to get the current old one up to date.
> >> >
> >> > Erik.
> >> >
> >> >> -----Original Message-----
> >> >> From: Phil Davies [mailto:de...@gm...]
> >> >> Sent: Monday, July 11, 2011 10:56 AM
> >> >> To: Development list for Rails: an 18xx game
> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >>
> >> >> As far as I'm concerned it's really Brett, Erik and Stefan's
> >> >> decision
> >> > being the
> >> >> primary contributors to the project.  IntelliJ has a Git plugin so
> >> >> I'm
> >> > sure I'll
> >> >> work it out :)
> >> >>
> >> >> Phil
> >> >>
> >> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
> >> >> > Erik & Brett,
> >> >> > given that you both had some long-time hands-on-experience with
> >> >> > Maven (compared to my third-party recommendation and a short
> >> >> > try-out) I agree to stay with the current setup.
> >> >> > I had not tested EGit/JGit before, thus I considered them as
> >> >> > competing products similar to the svn-support in eclipse ;-)
> >> >> > Stefan
> >> >> >
> >> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
> >> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...>
> wrote:
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: Stefan Frey [mailto:ste...@we...]
> >> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
> >> >> >> >> To: Development list for Rails: an 18xx game
> >> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
> >> >> >> >>
> >> >> >> >> Erik & Brett,
> >> >> >> >> I am up for that move. Do you recommend JGit or Egit?
> >> >> >> >
> >> >> >> > AFAIK you need both (in Eclipse).
> >> >> >>
> >> >> >> Correct.
> >> >> >>
> >> >> >> JGit is the java git implementation.
> >> >> >> EGit is the eclipse plugin built on top of JGit.
> >> >> >>
> >> >> >> >> I am wondering if you would consider to move to a maven
> >> >> >> >> build at the same time. Ideally by changing to the maven
> >> >> >> >> recommended repo
> >> >> layout.
> >> >> >> >
> >> >> >> > Dunno. Brett is handling the builds (I only run either from
> >> >> >> > Eclipse Run or from the published Rails jars).
> >> >> >> >
> >> >> >> > I hardly know anything about Maven. In the past I have been
> >> >> >> > half-involved with some (old) projects that used Maven, and
> >> >> >> > perhaps
> >> >> some other stuff.
> >> >> >> > What I remember about these projects was the ubiquitous
> >> >> >> > presence of pom.xml files that did not mean anything to me (I
> >> >> >> > wasn't really interested either - it worked). So I'm blank.
> >> >> >>
> >> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
> >> >> >> Maven
> >> >> >> 3 matures, it will improve in crucial areas. Right now, I
> >> >> >> really dislike the way it handles dependency resolution, among
> other things.
> >> >> >>
> >> >> >> > Perhaps we'll better restrict ourselves to one major step at a
> time?
> >> >> >>
> >> >> >> Agreed.
> >> >> >>
> >> >> >> > One thing on our Git repo that I have struggled with
> >> >> >> > yesterday is that it seems to require that the .git directory
> >> >> >> > would exist at the same level as all project directories
> >> >> >> > (game, tile, data etc.).  I was trying to get these
> >> >> >> > directories below a src directory on the same level as .git
> >> >> >> > (under the project root), but failed  to get there. Not
> >> >> >> > really a problem, but perhaps
> >> noteworthy.
> >> >> >> >
> >> >> >> > Erik.
> >> >> >>
> >> >> >> ---Brett.
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ---
> >> >> >> ---
> >> >> >> ------
> >> >> >> --- All of the data generated in your IT infrastructure is
> >> >> >> seriously valuable. Why? It contains a definitive record of
> >> >> >> application performance, security threats, fraudulent activity,
> >> >> >> and more. Splunk takes this data and makes sense of it. IT
> >> >> >> sense. And
> >> common sense.
> >> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> >> _______________________________________________
> >> >> >> Rails-devel mailing list
> >> >> >> Rai...@li...
> >> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> >
> >> >> > ----------------------------------------------------------------
> >> >> > ---
> >> >> > ---
> >> >> > -------- All of the data generated in your IT infrastructure is
> >> >> > seriously valuable.
> >> >> > Why? It contains a definitive record of application performance,
> >> >> > security threats, fraudulent activity, and more. Splunk takes
> >> >> > this data and makes sense of it. IT sense. And common sense.
> >> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> >> > _______________________________________________
> >> >> > Rails-devel mailing list
> >> >> > Rai...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >> >
> >> >>
> >> >>
> >> > -------------------------------------------------------------------
> >> > ---
> >> > ------
> >> > --
> >> >> All of the data generated in your IT infrastructure is seriously valuable.
> >> >> Why? It contains a definitive record of application performance,
> >> >> security threats, fraudulent activity, and more. Splunk takes this
> >> >> data and makes sense of it. IT sense. And common sense.
> >> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- All of the data generated in your IT infrastructure is
> >> > seriously valuable.
> >> > Why? It contains a definitive record of application performance,
> >> > security threats, fraudulent activity, and more. Splunk takes this
> >> > data and makes sense of it. IT sense. And common sense.
> >> > http://p.sf.net/sfu/splunk-d2d-c2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> --------- All of the data generated in your IT infrastructure is
> >> seriously valuable.
> >> Why? It contains a definitive record of application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- All of the data generated in your IT infrastructure is
> > seriously valuable.
> > Why? It contains a definitive record of application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Git repository is now available.

[Bill R. <ro...@gm...>]

I'm somewhat new to Git and so have a workflow question.  Let me know if the following seems reasonable, especially step 3:

1. Alice wishes to add a new feature (say, support for 1848).  She creates a local branch (1848-dev) and begins work.

2. Alice makes several commits to her local branch while implementing this feature.  In the mean-time, the master branch will have also changed.

3. Alice rebases her local branch on top of the current state of the master branch and fixes any conflicts.  As she does this she squashes all of her local commits into one commit as the rest of the developers probably don't want or need all of her committed but only partially implemented versions of the feature.

4. Now that her local branch is one commit away from the current master, Alice creates and sends a patch that implements the new feature.

(I'm still working on 1848, but it's quite far being from done: I haven't sent anything, as I don't know how useful it is to have another partially implemented (unplayable) game.)

Bill

On 2011-07-18, at 3:19 , brett lentz wrote:

> I've migrated all of the commits up to r1614 from SVN into the Git
> repository on SF.net.
> 
> Currently, none of the tags have been migrated due to differences in
> how SVN and Git handle tags. I'll be pushing the tags up as soon as I
> have them ready.
> 
> Important note for committers:
> 
> Please set up your .gitconfig to include your name and e-mail address
> for all future commits.
> 
> During the migration, you'll note I've converted all existing commits
> to use this information. To have the tree remain consistent, you'll
> need to follow suit.
> 
> ---Brett.
> 
> 
> 
> On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
>> That would be great.  Thanks.
>> Erik.
>> 
>>> -----Original Message-----
>>> From: brett lentz [mailto:bre...@gm...]
>>> Sent: Monday, July 11, 2011 9:45 PM
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>> 
>>> I'll work on it this week.  This coming weekend should be a good target for
>>> the cutover.
>>> 
>>> ---Brett.
>>> 
>>> 
>>> 
>>> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
>>>> OK, it seems we are ready then for the switchover.
>>>> 
>>>> Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
>>>> I suppose it's better to create a fresh new repository than to do a
>>>> massive update to get the current old one up to date.
>>>> 
>>>> Erik.
>>>> 
>>>>> -----Original Message-----
>>>>> From: Phil Davies [mailto:de...@gm...]
>>>>> Sent: Monday, July 11, 2011 10:56 AM
>>>>> To: Development list for Rails: an 18xx game
>>>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>>>> 
>>>>> As far as I'm concerned it's really Brett, Erik and Stefan's decision
>>>> being the
>>>>> primary contributors to the project.  IntelliJ has a Git plugin so
>>>>> I'm
>>>> sure I'll
>>>>> work it out :)
>>>>> 
>>>>> Phil
>>>>> 
>>>>> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>>>>>> Erik & Brett,
>>>>>> given that you both had some long-time hands-on-experience with
>>>>>> Maven (compared to my third-party recommendation and a short
>>>>>> try-out) I agree to stay with the current setup.
>>>>>> I had not tested EGit/JGit before, thus I considered them as
>>>>>> competing products similar to the svn-support in eclipse ;-) Stefan
>>>>>> 
>>>>>> On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>>>>>>> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefan Frey [mailto:ste...@we...]
>>>>>>>>> Sent: Sunday, July 10, 2011 2:42 PM
>>>>>>>>> To: Development list for Rails: an 18xx game
>>>>>>>>> Subject: Re: [Rails-devel] Are we ready for Git?
>>>>>>>>> 
>>>>>>>>> Erik & Brett,
>>>>>>>>> I am up for that move. Do you recommend JGit or Egit?
>>>>>>>> 
>>>>>>>> AFAIK you need both (in Eclipse).
>>>>>>> 
>>>>>>> Correct.
>>>>>>> 
>>>>>>> JGit is the java git implementation.
>>>>>>> EGit is the eclipse plugin built on top of JGit.
>>>>>>> 
>>>>>>>>> I am wondering if you would consider to move to a maven  build
>>>>>>>>> at the same time. Ideally by changing to the maven recommended
>>>>>>>>> repo
>>>>> layout.
>>>>>>>> 
>>>>>>>> Dunno. Brett is handling the builds (I only run either from
>>>>>>>> Eclipse Run or from the published Rails jars).
>>>>>>>> 
>>>>>>>> I hardly know anything about Maven. In the past I have been
>>>>>>>> half-involved with some (old) projects that used Maven, and
>>>>>>>> perhaps
>>>>> some other stuff.
>>>>>>>> What I remember about these projects was the ubiquitous presence
>>>>>>>> of pom.xml files that did not mean anything to me (I wasn't
>>>>>>>> really interested either - it worked). So I'm blank.
>>>>>>> 
>>>>>>> I deal with Maven at my day job, and I'm not a fan. Perhaps as
>>>>>>> Maven
>>>>>>> 3 matures, it will improve in crucial areas. Right now, I really
>>>>>>> dislike the way it handles dependency resolution, among other things.
>>>>>>> 
>>>>>>>> Perhaps we'll better restrict ourselves to one major step at a time?
>>>>>>> 
>>>>>>> Agreed.
>>>>>>> 
>>>>>>>> One thing on our Git repo that I have struggled with yesterday
>>>>>>>> is that it seems to require that the .git directory would exist
>>>>>>>> at the same level as all project directories (game, tile, data
>>>>>>>> etc.).  I was trying to get these directories below a src
>>>>>>>> directory on the same level as .git (under the project root),
>>>>>>>> but failed  to get there. Not really a problem, but perhaps
>>> noteworthy.
>>>>>>>> 
>>>>>>>> Erik.
>>>>>>> 
>>>>>>> ---Brett.
>>>>>>> 
>>>>>>> ------------------------------------------------------------------
>>>>>>> ---
>>>>>>> ------
>>>>>>> --- All of the data generated in your IT infrastructure is
>>>>>>> seriously valuable. Why? It contains a definitive record of
>>>>>>> application performance, security threats, fraudulent activity,
>>>>>>> and more. Splunk takes this data and makes sense of it. IT sense. And
>>> common sense.
>>>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>>>> _______________________________________________
>>>>>>> Rails-devel mailing list
>>>>>>> Rai...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>> 
>>>>>> -------------------------------------------------------------------
>>>>>> ---
>>>>>> -------- All of the data generated in your IT infrastructure is
>>>>>> seriously valuable.
>>>>>> Why? It contains a definitive record of application performance,
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>>> _______________________________________________
>>>>>> Rails-devel mailing list
>>>>>> Rai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>> 
>>>>> 
>>>>> 
>>>> ----------------------------------------------------------------------
>>>> ------
>>>> --
>>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>>> Why? It contains a definitive record of application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> -------- All of the data generated in your IT infrastructure is
>>>> seriously valuable.
>>>> Why? It contains a definitive record of application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2d-c2
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Git repository is now available.

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

I've migrated all of the commits up to r1614 from SVN into the Git
repository on SF.net.

Currently, none of the tags have been migrated due to differences in
how SVN and Git handle tags. I'll be pushing the tags up as soon as I
have them ready.

Important note for committers:

Please set up your .gitconfig to include your name and e-mail address
for all future commits.

During the migration, you'll note I've converted all existing commits
to use this information. To have the tree remain consistent, you'll
need to follow suit.

---Brett.



On Mon, Jul 11, 2011 at 1:31 PM, Erik Vos <eri...@xs...> wrote:
> That would be great.  Thanks.
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>> Sent: Monday, July 11, 2011 9:45 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Are we ready for Git?
>>
>> I'll work on it this week.  This coming weekend should be a good target for
>> the cutover.
>>
>> ---Brett.
>>
>>
>>
>> On Mon, Jul 11, 2011 at 12:32 PM, Erik Vos <eri...@xs...> wrote:
>> > OK, it seems we are ready then for the switchover.
>> >
>> > Brett, when do you think you can have rebuilt the Git repo at Sourceforge?
>> > I suppose it's better to create a fresh new repository than to do a
>> > massive update to get the current old one up to date.
>> >
>> > Erik.
>> >
>> >> -----Original Message-----
>> >> From: Phil Davies [mailto:de...@gm...]
>> >> Sent: Monday, July 11, 2011 10:56 AM
>> >> To: Development list for Rails: an 18xx game
>> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >>
>> >> As far as I'm concerned it's really Brett, Erik and Stefan's decision
>> > being the
>> >> primary contributors to the project.  IntelliJ has a Git plugin so
>> >> I'm
>> > sure I'll
>> >> work it out :)
>> >>
>> >> Phil
>> >>
>> >> On 11 July 2011 06:04, Stefan Frey <ste...@we...> wrote:
>> >> > Erik & Brett,
>> >> > given that you both had some long-time hands-on-experience with
>> >> > Maven (compared to my third-party recommendation and a short
>> >> > try-out) I agree to stay with the current setup.
>> >> > I had not tested EGit/JGit before, thus I considered them as
>> >> > competing products similar to the svn-support in eclipse ;-) Stefan
>> >> >
>> >> > On Sunday, July 10, 2011 07:08:05 pm brett lentz wrote:
>> >> >> On Sun, Jul 10, 2011 at 9:24 AM, Erik Vos <eri...@xs...> wrote:
>> >> >> >> -----Original Message-----
>> >> >> >> From: Stefan Frey [mailto:ste...@we...]
>> >> >> >> Sent: Sunday, July 10, 2011 2:42 PM
>> >> >> >> To: Development list for Rails: an 18xx game
>> >> >> >> Subject: Re: [Rails-devel] Are we ready for Git?
>> >> >> >>
>> >> >> >> Erik & Brett,
>> >> >> >> I am up for that move. Do you recommend JGit or Egit?
>> >> >> >
>> >> >> > AFAIK you need both (in Eclipse).
>> >> >>
>> >> >> Correct.
>> >> >>
>> >> >> JGit is the java git implementation.
>> >> >> EGit is the eclipse plugin built on top of JGit.
>> >> >>
>> >> >> >> I am wondering if you would consider to move to a maven  build
>> >> >> >> at the same time. Ideally by changing to the maven recommended
>> >> >> >> repo
>> >> layout.
>> >> >> >
>> >> >> > Dunno. Brett is handling the builds (I only run either from
>> >> >> > Eclipse Run or from the published Rails jars).
>> >> >> >
>> >> >> > I hardly know anything about Maven. In the past I have been
>> >> >> > half-involved with some (old) projects that used Maven, and
>> >> >> > perhaps
>> >> some other stuff.
>> >> >> > What I remember about these projects was the ubiquitous presence
>> >> >> > of pom.xml files that did not mean anything to me (I wasn't
>> >> >> > really interested either - it worked). So I'm blank.
>> >> >>
>> >> >> I deal with Maven at my day job, and I'm not a fan. Perhaps as
>> >> >> Maven
>> >> >> 3 matures, it will improve in crucial areas. Right now, I really
>> >> >> dislike the way it handles dependency resolution, among other things.
>> >> >>
>> >> >> > Perhaps we'll better restrict ourselves to one major step at a time?
>> >> >>
>> >> >> Agreed.
>> >> >>
>> >> >> > One thing on our Git repo that I have struggled with yesterday
>> >> >> > is that it seems to require that the .git directory would exist
>> >> >> > at the same level as all project directories (game, tile, data
>> >> >> > etc.).  I was trying to get these directories below a src
>> >> >> > directory on the same level as .git (under the project root),
>> >> >> > but failed  to get there. Not really a problem, but perhaps
>> noteworthy.
>> >> >> >
>> >> >> > Erik.
>> >> >>
>> >> >> ---Brett.
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> ---
>> >> >> ------
>> >> >> --- All of the data generated in your IT infrastructure is
>> >> >> seriously valuable. Why? It contains a definitive record of
>> >> >> application performance, security threats, fraudulent activity,
>> >> >> and more. Splunk takes this data and makes sense of it. IT sense. And
>> common sense.
>> >> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> >> _______________________________________________
>> >> >> Rails-devel mailing list
>> >> >> Rai...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >> > -------------------------------------------------------------------
>> >> > ---
>> >> > -------- All of the data generated in your IT infrastructure is
>> >> > seriously valuable.
>> >> > Why? It contains a definitive record of application performance,
>> >> > security threats, fraudulent activity, and more. Splunk takes this
>> >> > data and makes sense of it. IT sense. And common sense.
>> >> > http://p.sf.net/sfu/splunk-d2d-c2
>> >> > _______________________________________________
>> >> > Rails-devel mailing list
>> >> > Rai...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >> >
>> >>
>> >>
>> > ----------------------------------------------------------------------
>> > ------
>> > --
>> >> All of the data generated in your IT infrastructure is seriously valuable.
>> >> Why? It contains a definitive record of application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-d2d-c2
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> > ----------------------------------------------------------------------
>> > -------- All of the data generated in your IT infrastructure is
>> > seriously valuable.
>> > Why? It contains a definitive record of application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2d-c2
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Tile orientation display

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

> The point of a canonical orientation is that there is only one (if there is
> more than one, such as for tile #9, then they are indistinguishable for all
> purposes).  I'm not sure which canonical rules you are referring to, but in
> the one I proposed (and use) there is exactly one possible base orientation
> for #25, which is branches from D to B and F.  You have other cases that
> have to be dealt with in the canonical rules, such as when there is internal
> connectivity, such as between multiple city clusters and external exits, but
> it is easy enough to extend the canonicalization rules to accomodate those.
> 
John,
thanks for the clarification.

I referred to the definition from the 18xx yahoo message Erik pointed to 
(copied below).

I now understand my mistake:
The vertical axis of 3) runs perpendicular from the middle of side D to the 
middle of side A, instead of my understanding that it refers to the "diagonal" 
going from the corner between D/E to the corner A/B.
But I am still wondering about the wording of 3) as it refers only to the 
symmetry of the exits, not of the track configuration. 

I checked the discussion thread again, and John David Galt came up with a good 
solution for that:

2.5) if the track on a tile is a "switch" (like a tree where one "trunk"
splits into two or more "branches"), the D position is always the "trunk".
If the tile has multiple "switches" on it, D must be one of the "trunks".

Depending on the orientation (hex standing on the base D or balancing of the 
corner between D/E) "vertical axis" can vary. 
I used 
http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
to check the definition and got confused by that.

Is there are another definition that describes the same configuration that is 
better suited for programming instead of having to check for symmetry against 
the vertical axis?

My current proposal for an algorithm of the canonical orientation is the 
following:

W can gladly ignore 1) as the orientation will be for a general database of 
tiles, not a game specific one (this is taken care somewhere else).

On first glance it seems that assigning points (think binary if you like) to 
the exits or exit combinations ensures the rules.

2) Exit at D = 10000
2.5) Two tracks ending at D = 1000
3) Exits at A&D = 100
3) Exits at B&E = 100
3) Exits at C&F = 100
4+5) Exit at C= 11
4) Exit at A = 10
4) Exit at B = 10

The prefix x) refers to the rule covered by assigning points.

Stefan

John's Definition copied here:

1) if a tile may only be played on a specific place on the map in a
specific orientation, orient the tile so that up on the tile reflects up
on the map.
2) one exit must be in the D position
3) if the exits can be arranged such that they are symmetrical across the
vertical axis, it must be arranged so.
4) if the exits can be arranged to only be on A, B, C, and D, it must be
arranged so.
5) prefer orientations that leave B empty over ones that leave C empty.

And JDG's definition again:

2.5) if the track on a tile is a "switch" (like a tree where one "trunk"
splits into two or more "branches"), the D position is always the "trunk".
If the tile has multiple "switches" on it, D must be one of the "trunks".

[Rails-devel] Todo lists, release notes and the Wiki

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 14, 2011 7:51 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Refactored loading code
> 
> This seems like duplication of work: The repository already keeps a
history of
> the change-logs. I believe it will be the same for git. Thus I am
reluctant to
> copy the logs into the wiki manually.

The wiki change log is intended as raw material for Release Notes.  Brett
did that for 1.4.1, and I did it for 1.4.2.  I personally find the separate
log easier to work with, and it also allows me to add the names of the
people who have contributed to each change.  

> What I think would be helpful (and I did that once already) to attach the
> revision number after the e-mail accompanying the commit (if there is
any).
> In combination with blame this would really help to find out, what was the
> idea behind the change. I quite often search the Rails archive for more
info of
> a change.
> 
> I have not checked if there is a revision number of the sf-git repository
and
> potentially it might be better to copy the main parts of the e-mail into
> (additional) javadoc document(s).

No, unfortunately we will lose the revision numbers.  Git identifies changes
with 32 hex digit hashes of their contents, and I read that it is somewhat
conventional to use the first 6 characters of these hashes to identify
changes in human interactions.  I'm not aware of any method to humanize that
any further.
 
> Instead of adding the history of development to the wiki I suggest to add
a
> development roadmap/todo-list to the wiki.
> Especially with local repositories it gets more likely that several people
are
> working on the same stuff, which is both a waste of resources and makes
> code merging difficult. And it might even attract new people, if they know
> where to start and what is needed.

Yeah, various people have already done bits of that, but it needs more work.


Now that I have paused development until the transfer to Git has completed,
I'm digging through my enormous Inbox to collect and group the requests and
ideas for generic actions per subject and specific actions per game.  My
hope is that this will help to get myself organized a bit better (not my
best skill, I must admit), and perhaps I could use it as base material for
the Wiki.  

Erik.

 
> Stefan
> 
> 
> 
> >
> > As you may or may not have noticed, since some time I'm pretty
> > meticulously creating entries in the Wiki Change Log for all my
> > commits (except very trivial ones).  I don't know if I can expect the
> > same from Brett and you (as we have seen earlier today, I'm not really
> > the right person to request discipline). In any case, I have just
> > created simple entries for the recent commits 1602-1604 by the two of
> > you.  Feel free to  correct or expand.

Re: [Rails-devel] Tile orientation display

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

Thanks, Stefan, I now better understand what you're after.  Sounds good.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, July 16, 2011 8:03 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tile orientation display
> 
> Erik:
> imho the canonical orientation intends to solve same issue, however it
uses a
> different algorithm, thus there will be different orientations.
> 
> And it seems that it does not orientate tile 25 (switch with two broad
curves)
> uniquely: There are three configurations that have identical position of
the
> exits: The switch can either be in position D, F or B, however exits are
still
> always B, D and F.
> This problem arises for all tiles with symmetrical exits, but asymmetrical
> tracks.
> But maybe I have misunderstood something there (likely given the expertise
> of the discussants).
> 
> For neither mine nor the canonical one the reference point is important
and
> can be chosen.
> 
> In any case the re-orientation will be done by programming code, not by
> editing all tiles with the TileDesigner ;-) I never intended to propose
that.
> What a horrible idea ...
> 
> The idea is to create an (base)orientation-attribute like you suggested
> previously, but not manually.
> 
> Stefan
> 
> 
> The canonical orientation copied here for reference:
> 
> >> As I went through tiles, I came up with new rules and simplified some
> >> others, so there is still much to be done to get the entire tile
> >> database consistent with these rules (orientations for flat-bottom
> >> tiles are A at the top, following clockwise from there -- flat-side
> >> tiles are rotated 30 degrees [ie, A is northeast and F is northwest]).
> >>
> >> 1) if a tile may only be played on a specific place on the map in a
> >> specific orientation, orient the tile so that up on the tile reflects
> >> up on the map.
> >> 2) one exit must be in the D position
> >> 3) if the exits can be arranged such that they are symmetrical across
> >> the vertical axis, it must be arranged so.
> >> 4) if the exits can be arranged to only be on A, B, C, and D, it must
> >> be arranged so.
> >> 5) prefer orientations that leave B empty over ones that leave C empty.
> 
> 
> 
> 
> 
> On Thursday, July 14, 2011 11:09:23 am Erik Vos wrote:
> > Stefan,
> >
> > Thanks for the clarification (I didn't find it irritating, but missed
> > the background).
> >
> > About the "natural" tile orientation: there has been a similar
> > discussion in the [18xx] group a few months ago.  See message #31521,
> > where Scott pointed to John Tamplin's "canonical orientation" and
> > Steve Thomas commented upon that.  Could it be beneficial to align with
> that proposal?
> >
> > The trouble with any standard tile orientation that is different from
> > the usual ones (with the number at S or SW), is that it is meaningless
> > to anyone who has not internalized the algorithm to define it (and I
> > would have trouble doing that).  To fix that, we would need to change
> > all tile rotations in TileDesigner to align with the new rule.  That's
> > not impossible, but a lot of work...
> >
> > I hope I'm still understanding you right...
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Thursday, July 14, 2011 7:38 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Tile orientation display
> > >
> > > Edward & Erik,
> > >
> > > sorry for the (irritating) mail: Erik guessed right, this was a
> > > copy from
> >
> > a more
> >
> > > extended document about my thoughts to create the complete logic for
> > > tile laying and upgrading. This would prevent any illegal tile-lay
> > > and thus
> >
> > needs to
> >
> > > consider the various upgrade rules (permissive, semi-restrictive and
> > > restrictive) and cope with all the little details the human mind can
> >
> > easily
> >
> > > solve, but are difficult for an algorithm.
> > >
> > > This is not yet finished as I am not satisfied with neither the text
> > > nor
> >
> > the
> >
> > > proposed design. And it would require a substantial rewrote of the
> > > UI,
> >
> > which
> >
> > > I would delay until it is decided which client/server model and what
> > > kind
> >
> > of
> >
> > > (mobile) devices Rails will support in the future.
> > >
> > > However what I proposed below is a (very simple) rule to create a
> > > natural orientation of each tile, which is only defined by the
> > > actual track configuration of the tile. This avoids arbitrary rules
> > > like the location
> >
> > of tile id,
> >
> > > which result in different orientations of the same tile between
> > > different
> >
> > 18xx
> >
> > > titles (or even inside one game as reported on the yahoo list).
> > >
> > > Another advantage is that allows someone to redraw/redesign the
> > > artwork of the tile and then the algorithm would still define the
> > > same base
> >
> > rotation.
> >
> > > Other than this the rule makes my (yet unpublished) algorithm to
> > > choose
> >
> > the
> >
> > > allowed upgrade rotations more efficient and is part of the problem
> > > to identify symmetric orientations (there are only 3 possible
> > > orientations
> >
> > for the
> >
> > > straight line, not 6). But that part was impossible to understand
> > > without
> >
> > the
> >
> > > context.
> > >
> > > Stefan
> > >
> > > On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote:
> > > > Thinking about it (I should do that more often :-), Stefan is
> > > > probably working on making the rotation logic route-aware (as in:
> > > > "some new track must be part of a valid route" and all its
> > > > variations). The current code isn't.
> > > >
> > > > Erik.
> > > >
> > > > > -----Original Message-----
> > > > > From: Erik Vos [mailto:eri...@xs...]
> > > > > Sent: Wednesday, July 13, 2011 10:02 AM
> > > > > To: 'Development list for Rails: an 18xx game'
> > > > > Subject: Re: [Rails-devel] Tile orientation display
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Edward S. Rustin [mailto:ed...@we...]
> > > > > >
> > > > > > Having read all that, I do have to wonder about one thing -
> > > > > > what's the problem you're trying to solve?
> > > > >
> > > > > That also was my first question. I can imagine that some clever
> > > > > algorithm would make it easier to determine the valid rotations
> > > > > of a
> >
> > laid
> >
> > > tile.
> > >
> > > > > Currently that's pretty messy code of my making (see
> > > > > GUITile.rotate()),
> > > >
> > > > and
> > > >
> > > > > if Stefan sees ways to improve/simplify that, I'm all for it.
> > > > >
> > > > > Unfortunately, I don't yet see how Stefan's calculations would
> > > > > improve the situation, so I can't provide any more substantial
> > >
> > > commentary.
> > >
> > > > > The allowed rotations of tiles #64-68 (the tile #59 upgrades)
> > > > > were hardest
> > > >
> > > > to
> > > >
> > > > > get right, so that's a main test case.
> > > > >
> > > > > > It might just be my lack of knowledge about Rails (although
> > > > > > I've been
> > > > >
> > > > > picking
> > > > >
> > > > > > some up here and there from lurking on here and prodding the
> > > > > > source), but I'm really not sure what the purpose of your
> > > > > > algorithm is. Surely for any
> > > > >
> > > > > given
> > > > >
> > > > > > 18xx game, there's a specified upgrade path where Tile X can
> > > > > > be upgraded
> > > > >
> > > > > to
> > > > >
> > > > > > Tile Y or Tile Z, and there's only going to be a few unique
> > > > > > mappings based
> > > > >
> > > > > on
> > > > >
> > > > > > orientation.
> > > > > >
> > > > > > As a side point, your algorithm might work better were you to
> > > > > > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six
> > > > > > bit binary
> > > > > > value) so that you avoid the problem of two different tiles
> > > > > > having the
> > > > >
> > > > > same
> > > > >
> > > > > > value (a tile with exits at 1, 2, 5 has the same value as one
> > > > > > with exits
> > > > >
> > > > > at 1, 3, 4
> > > > >
> > > > > > for example).
> > > > >
> > > > > Another side point: as we currently use S/SW=0, wouldn't it be
> > > > > less
> > > >
> > > > confusing
> > > >
> > > > > to stick with that start point for side numbering? Or doesn't it
> > > > > make a difference?
> > > > >
> > > > > > On Wed, Jul 13, 2011 at 06:55, Stefan Frey
> > > > > > <ste...@we...>
> > >
> > > wrote:
> > > > > > > Somehow related to the discussion and I would be happy to
> > > > > > > hear suggestions and comments on that problem:
> > > > > > >
> > > > > > > After finishing the RevenueCalculation algorithms I started
> > > > > > > to design/outline the workflow of an UpgradeTile algorithm.
> > > > > > >
> > > > > > > To make this efficient I intended to make the base rotation
> > > > > > > of all tiles such that it allows the upgrades to fit with
> > > > > > > minimal
> >
> > rotations.
> >
> > > > > > > What is the idea behind this? Take the example how Keith
> > > > > > > Thomasson built his tile sheets for postal play.
> > > > > > >
> > > > > > > Check the tile sheet of:
> > > > > > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > > > > > It seems that in many cases those tiles are already
> > > > > > > orientated to allow for easy upgrades:
> > > > > > >
> > > > > > > Define Facing 1 as the base rotation of an tile. Then it is
> > > > > > > the case for example for an upgrade from tile 8 to tiles 19,
> > > > > > > 24, 29 the possible upgrade will keep facings identical
> > > > > > > (thus no rotation of the upgraded tiles is required). To
> > > > > > > upgrade to tile
> > > > > > > 16 and 25 one of the possible upgrades has identical facings.
> > > > > > >
> > > > > > > So I came up with the idea if there is a solution that
> > > > > > > allows to define an algorithm that defines a base rotations
> > > > > > > for all tiles such that upgrades can be done with only a few
> rotations.
> > > > > > >
> > > > > > > At that time my idea was the following:
> > > > > > > Id each hex side (for the example start with NW = 0, NE = 1,
...
> > > > > > > , W =
> > > > > > > 5)
> > > > > > >
> > > > > > > A) Then sum up the id of all sides with at least one track
> > > > > > > leading to it. Call that X. Compare each possible facing and
> > > > > > > choose that with minimal X as the base rotation.
> > > > > > >
> > > > > > > It is easy to check that tiles 7, 8 and 9 are optimal
> > > > > > > rotated given in that definition (and starting id=0 from NW).
> > > > > > >
> > > > > > > It is also the case for 16, 18, 19. However not for 20
> > > > > > > (facing 2 has minimal ids), and 23 (here facing 4), but again
for 24.
> > > > > > >
> > > > > > > For tile 25 facing 1 and 3 have the same X. So a secondary
> > > > > > > criteria would be helpful. Thus
> > > > > > >
> > > > > > > B) Sum up the ids of all tracks => Y So given same X, then
> > > > > > > choose minimal Y as the base rotation.
> > > > > > >
> > > > > > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and
> > > > > > > from
> > > > > > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to
> > > > > > > id=2 and from
> > > > > > > id=2 to id=4 thus Y=8.
> > > > > > >
> > > > > > > C) What about tiles with stations on it? If you have only
> > > > > > > one station which is connected to all tracks you can easily
> > > > > > > rely on
> > > >
> > > > ranking by X:
> > > > > > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > > > > > >
> > > > > > > If you have two stations the minimal rotation is always
> > > > > > > found by ranking with X and Y as long as the stations have
> > > > > > > identical attributes and number of tracks.
> > > > > > >
> > > > > > > However in other cases it can get more difficult and one
> > > > > > > still has to fall back to some base rotation defined in the
> > > > > > > master
> >
> > database.
> >
> > > > > > > (One Example is tile 11 in
> > >
> > >
> http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > >
> > > > > > m
> > > > > >
> > > > > > > ). Facing 1, 3 and 5 have same X and Y.
> > > > > > >
> > > > > > > Related to this is he issue of symmetry: For example tile 9
> > > > > > > has a potential facing 4 (which is the rotation by 180
> > > > > > > degree, but as tile
> > > > > > > 9 has exactly a symmetry there, this facing can ignored). So
> > > > > > > identity in X and Y is a necessary condition for symmetry.
> > > > > > > For the
> > > > > > > 1830 tile set it is also a sufficient condition (as far as I
> > > > > > > have checked, correct me if I am wrong)
> > > > > > >
> > > > > > > In general the identity of X and Y is not a sufficient
> > > > > > > condition for all
> > > > > > > (existing) 18xx tiles (see example above) and if someone
> > > > > > > proposes an algorithm that covers more cases than mine I
> > > > > > > would be
> > >
> > > very grateful.
> > >
> > > > > > > But for my case (an efficient algorithm) a necessary
> > > > > > > condition that is easy to calculate is already very helpful
> > > > > > > as the more complex check is only needed for those cases not
> > > > > > > eliminated by the simple one (similar to a hash code to test
> equality).
> > > > > > >
> > > > > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > > > > > >> The currently ongoing discussion in the [18xx] group on how
> > > > > > >> to describe tile lays is also of interest for Rails.  I'm
> > > > > > >> in particular referring to cases where the Rails
> > > > > > >> (TileDesigner) tile orientation (i.e., the tile number
> > > > > > >> placement)  is different from the physical game. I just
> > > > > > >> checked
> > > > > > >> 1830 and 1856. The 1830 tile orientations are the same as
> > > > > > >> in Rails (except tile #65), whereas with 1856 there are
> > > > > > >> many
> > >
> > > differences.
> > >
> > > > > > >> Take tile #23 as an example. The 1856 orientation of this
> > > > > > >> tile is upside-down as compared with 1830 and Rails.  Now
> > > > > > >> assume tile #9 has been laid before on hex O10 (connecting
> > > > > > >> SW-NE) and is upgraded to tile #23 (adding a connection
> > > > > > >> NW-NE).  Now the question is: how to display this upgrade
> > > > > > >> in the map window and
> >
> > the
> >
> > > game report?
> > >
> > > > > > >> The Rails tile has the number as in 1830, on the SW side in
> > > > > > >> this case, so the upgrade is now coded as #23/O10/SW.
> > > > > > >> However, the physical tile would have its number on the NE
> > > > > > >> side, so in an FTF game the upgrade would be denoted as
> #23/O10/NE.
> > > > > > >>
> > > > > > >> My question is: what do we prefer?
> > > > > > >>
> > > > > > >> I am thinking on adding an optional attribute to <Tile> in
> > > > > > >> TileSet.xml that specifies the 'base rotation' of the
> > > > > > >> physical tile as compared with the Rails tile (or vice
> > > > > > >> versa). This 'base rotation' would then be added (or
> > > > > > >> subtracted) to the internal value to calculate the
> > > > > > >> displayed tile orientation.
> > > > > > >>
> > > > > > >> So, to make the laid tile in this example be described as
> > > > > > >> #23/O10/NE we should add an attribute like
'baseRotation="3"'.
> > > > > > >>
> > > > > > >> Any need for this feature? Should it  be an option?
> > > > > > >>
> > > > > > >> Erik.
> > > > > > >>
> > > > > > >>
> > > > > > >> -----------------------------------------------------------
> > > > > > >> ----
> > > > > > >> ----
> > > > > > >> --
> > > > > > >> ------
> > > > > > >> --- AppSumo Presents a FREE Video for the SourceForge
> > > > > > >> Community by Eric Ries, the creator of the Lean Startup
> > > > > > >> Methodology on "Lean Startup Secrets Revealed." This video
> > > > > > >> shows you how to validate your ideas, optimize your ideas
> > > > > > >> and identify your
> >
> > business
> >
> > > strategy.
> > >
> > > > > > >> http://p.sf.net/sfu/appsumosfdev2dev
> > > > > > >> _______________________________________________
> > > > > > >> Rails-devel mailing list
> > > > > > >> Rai...@li...
> > > > > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > -------- AppSumo Presents a FREE Video for the SourceForge
> > > > > > > Community by Eric Ries, the creator of the Lean Startup
> > > > > > > Methodology on "Lean Startup Secrets Revealed." This video
> > > > > > > shows you how to validate your ideas, optimize your ideas
> > > > > > > and identify
> >
> > your
> >
> > > business strategy.
> > >
> > > > > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > > > > _______________________________________________
> > > > > > > Rails-devel mailing list
> > > > > > > Rai...@li...
> > > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > -
> > > >
> > > > > --
> > > > >
> > > > > > AppSumo Presents a FREE Video for the SourceForge Community by
> > > > > > Eric Ries, the creator of the Lean Startup Methodology on
> > > > > > "Lean Startup Secrets Revealed." This video shows you how to
> > > > > > validate your ideas, optimize your ideas and identify your
> > > > > > business strategy. http://p.sf.net/sfu/appsumosfdev2dev
> > > > > > _______________________________________________
> > > > > > Rails-devel mailing list
> > > > > > Rai...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > - --
> > > >
> > > > > AppSumo Presents a FREE Video for the SourceForge Community by
> > > > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > > Startup Secrets Revealed." This video shows you how to validate
> > > > > your ideas, optimize your ideas and identify your business
strategy.
> > > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > --- AppSumo Presents a FREE Video for the SourceForge Community by
> > > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > Startup Secrets Revealed." This video shows you how to validate
> > > > your ideas, optimize your ideas and identify your business strategy.
> > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > > Secrets Revealed." This video shows you how to validate your ideas,
> > > optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- AppSumo Presents a FREE Video for the SourceForge Community by
> > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > Startup Secrets Revealed." This video shows you how to validate your
> > ideas, optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tile orientation display

[John A. T. <ja...@ja...>]

On Sat, Jul 16, 2011 at 2:02 AM, Stefan Frey <ste...@we...> wrote:

> imho the canonical orientation intends to solve same issue, however it uses
> a
> different algorithm, thus there will be different orientations.
>
> And it seems that it does not orientate tile 25 (switch with two broad
> curves)
> uniquely: There are three configurations that have identical position of
> the
> exits: The switch can either be in position D, F or B, however exits are
> still
> always B, D and F.
> This problem arises for all tiles with symmetrical exits, but asymmetrical
> tracks.
> But maybe I have misunderstood something there (likely given the expertise
> of
> the discussants).
>

The point of a canonical orientation is that there is only one (if there is
more than one, such as for tile #9, then they are indistinguishable for all
purposes).  I'm not sure which canonical rules you are referring to, but in
the one I proposed (and use) there is exactly one possible base orientation
for #25, which is branches from D to B and F.  You have other cases that
have to be dealt with in the canonical rules, such as when there is internal
connectivity, such as between multiple city clusters and external exits, but
it is easy enough to extend the canonicalization rules to accomodate those.

-- 
John A. Tamplin

[Rails-devel] TGV modifier for 1826

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

I used the (current) halt on the development on the base system of Rails to 
refine the dynamic modifier interface. This allows the support of the TGV (as 
defined in 1826).
In general the modifier allows to run trains in two separate sets: Each of the 
set runs independent of the other with respect to track usage.
However in 1826 only one TGV is allowed per company, but that must be 
restricted somewhere else in Rails.
I created a template in the wiki for 1826 development.
Stefan

Re: [Rails-devel] Tile orientation display

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

Erik:
imho the canonical orientation intends to solve same issue, however it uses a 
different algorithm, thus there will be different orientations.

And it seems that it does not orientate tile 25 (switch with two broad curves) 
uniquely: There are three configurations that have identical position of the 
exits: The switch can either be in position D, F or B, however exits are still 
always B, D and F.
This problem arises for all tiles with symmetrical exits, but asymmetrical 
tracks.
But maybe I have misunderstood something there (likely given the expertise of 
the discussants).

For neither mine nor the canonical one the reference point is important and 
can be chosen.

In any case the re-orientation will be done by programming code, not by 
editing all tiles with the TileDesigner ;-) I never intended to propose that. 
What a horrible idea ...

The idea is to create an (base)orientation-attribute like you suggested 
previously, but not manually.

Stefan


The canonical orientation copied here for reference:

>> As I went through tiles, I came up with new rules and simplified some
>> others, so there is still much to be done to get the entire tile database
>> consistent with these rules (orientations for flat-bottom tiles are A at
>> the top, following clockwise from there -- flat-side tiles are rotated 30
>> degrees [ie, A is northeast and F is northwest]).
>>
>> 1) if a tile may only be played on a specific place on the map in a
>> specific orientation, orient the tile so that up on the tile reflects up
>> on the map.
>> 2) one exit must be in the D position
>> 3) if the exits can be arranged such that they are symmetrical across the
>> vertical axis, it must be arranged so.
>> 4) if the exits can be arranged to only be on A, B, C, and D, it must be
>> arranged so.
>> 5) prefer orientations that leave B empty over ones that leave C empty.





On Thursday, July 14, 2011 11:09:23 am Erik Vos wrote:
> Stefan,
> 
> Thanks for the clarification (I didn't find it irritating, but missed the
> background).
> 
> About the "natural" tile orientation: there has been a similar discussion
> in the [18xx] group a few months ago.  See message #31521, where Scott
> pointed to John Tamplin's "canonical orientation" and Steve Thomas
> commented upon that.  Could it be beneficial to align with that proposal?
> 
> The trouble with any standard tile orientation that is different from the
> usual ones (with the number at S or SW), is that it is meaningless to
> anyone who has not internalized the algorithm to define it (and I would
> have trouble doing that).  To fix that, we would need to change all tile
> rotations in TileDesigner to align with the new rule.  That's not
> impossible, but a lot of work...
> 
> I hope I'm still understanding you right...
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, July 14, 2011 7:38 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Tile orientation display
> > 
> > Edward & Erik,
> > 
> > sorry for the (irritating) mail: Erik guessed right, this was a  copy
> > from
> 
> a more
> 
> > extended document about my thoughts to create the complete logic for tile
> > laying and upgrading. This would prevent any illegal tile-lay and thus
> 
> needs to
> 
> > consider the various upgrade rules (permissive, semi-restrictive and
> > restrictive) and cope with all the little details the human mind can
> 
> easily
> 
> > solve, but are difficult for an algorithm.
> > 
> > This is not yet finished as I am not satisfied with neither the text nor
> 
> the
> 
> > proposed design. And it would require a substantial rewrote of the UI,
> 
> which
> 
> > I would delay until it is decided which client/server model and what kind
> 
> of
> 
> > (mobile) devices Rails will support in the future.
> > 
> > However what I proposed below is a (very simple) rule to create a natural
> > orientation of each tile, which is only defined by the actual track
> > configuration of the tile. This avoids arbitrary rules like the location
> 
> of tile id,
> 
> > which result in different orientations of the same tile between different
> 
> 18xx
> 
> > titles (or even inside one game as reported on the yahoo list).
> > 
> > Another advantage is that allows someone to redraw/redesign the artwork
> > of the tile and then the algorithm would still define the same base
> 
> rotation.
> 
> > Other than this the rule makes my (yet unpublished) algorithm to choose
> 
> the
> 
> > allowed upgrade rotations more efficient and is part of the problem to
> > identify symmetric orientations (there are only 3 possible orientations
> 
> for the
> 
> > straight line, not 6). But that part was impossible to understand without
> 
> the
> 
> > context.
> > 
> > Stefan
> > 
> > On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote:
> > > Thinking about it (I should do that more often :-), Stefan is probably
> > > working on making the rotation logic route-aware (as in: "some new
> > > track must be part of a valid route" and all its variations). The
> > > current code isn't.
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Erik Vos [mailto:eri...@xs...]
> > > > Sent: Wednesday, July 13, 2011 10:02 AM
> > > > To: 'Development list for Rails: an 18xx game'
> > > > Subject: Re: [Rails-devel] Tile orientation display
> > > > 
> > > > > -----Original Message-----
> > > > > From: Edward S. Rustin [mailto:ed...@we...]
> > > > > 
> > > > > Having read all that, I do have to wonder about one thing - what's
> > > > > the problem you're trying to solve?
> > > > 
> > > > That also was my first question. I can imagine that some clever
> > > > algorithm would make it easier to determine the valid rotations of a
> 
> laid
> 
> > tile.
> > 
> > > > Currently that's pretty messy code of my making (see
> > > > GUITile.rotate()),
> > > 
> > > and
> > > 
> > > > if Stefan sees ways to improve/simplify that, I'm all for it.
> > > > 
> > > > Unfortunately, I don't yet see how Stefan's calculations would
> > > > improve the situation, so I can't provide any more substantial
> > 
> > commentary.
> > 
> > > > The allowed rotations of tiles #64-68 (the tile #59 upgrades) were
> > > > hardest
> > > 
> > > to
> > > 
> > > > get right, so that's a main test case.
> > > > 
> > > > > It might just be my lack of knowledge about Rails (although I've
> > > > > been
> > > > 
> > > > picking
> > > > 
> > > > > some up here and there from lurking on here and prodding the
> > > > > source), but I'm really not sure what the purpose of your
> > > > > algorithm is. Surely for any
> > > > 
> > > > given
> > > > 
> > > > > 18xx game, there's a specified upgrade path where Tile X can be
> > > > > upgraded
> > > > 
> > > > to
> > > > 
> > > > > Tile Y or Tile Z, and there's only going to be a few unique
> > > > > mappings based
> > > > 
> > > > on
> > > > 
> > > > > orientation.
> > > > > 
> > > > > As a side point, your algorithm might work better were you to
> > > > > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit
> > > > > binary
> > > > > value) so that you avoid the problem of two different tiles having
> > > > > the
> > > > 
> > > > same
> > > > 
> > > > > value (a tile with exits at 1, 2, 5 has the same value as one with
> > > > > exits
> > > > 
> > > > at 1, 3, 4
> > > > 
> > > > > for example).
> > > > 
> > > > Another side point: as we currently use S/SW=0, wouldn't it be less
> > > 
> > > confusing
> > > 
> > > > to stick with that start point for side numbering? Or doesn't it
> > > > make a difference?
> > > > 
> > > > > On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...>
> > 
> > wrote:
> > > > > > Somehow related to the discussion and I would be happy to hear
> > > > > > suggestions and comments on that problem:
> > > > > > 
> > > > > > After finishing the RevenueCalculation algorithms I started to
> > > > > > design/outline the workflow of an UpgradeTile algorithm.
> > > > > > 
> > > > > > To make this efficient I intended to make the base rotation of
> > > > > > all tiles such that it allows the upgrades to fit with minimal
> 
> rotations.
> 
> > > > > > What is the idea behind this? Take the example how Keith
> > > > > > Thomasson built his tile sheets for postal play.
> > > > > > 
> > > > > > Check the tile sheet of:
> > > > > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > > > > It seems that in many cases those tiles are already orientated
> > > > > > to allow for easy upgrades:
> > > > > > 
> > > > > > Define Facing 1 as the base rotation of an tile. Then it is the
> > > > > > case for example for an upgrade from tile 8 to tiles 19, 24, 29
> > > > > > the possible upgrade will keep facings identical (thus no
> > > > > > rotation of the upgraded tiles is required). To upgrade to tile
> > > > > > 16 and 25 one of the possible upgrades has identical facings.
> > > > > > 
> > > > > > So I came up with the idea if there is a solution that allows to
> > > > > > define an algorithm that defines a base rotations for all tiles
> > > > > > such that upgrades can be done with only a few rotations.
> > > > > > 
> > > > > > At that time my idea was the following:
> > > > > > Id each hex side (for the example start with NW = 0, NE = 1, ...
> > > > > > , W =
> > > > > > 5)
> > > > > > 
> > > > > > A) Then sum up the id of all sides with at least one track
> > > > > > leading to it. Call that X. Compare each possible facing and
> > > > > > choose that with minimal X as the base rotation.
> > > > > > 
> > > > > > It is easy to check that tiles 7, 8 and 9 are optimal rotated
> > > > > > given in that definition (and starting id=0 from NW).
> > > > > > 
> > > > > > It is also the case for 16, 18, 19. However not for 20 (facing 2
> > > > > > has minimal ids), and 23 (here facing 4), but again for 24.
> > > > > > 
> > > > > > For tile 25 facing 1 and 3 have the same X. So a secondary
> > > > > > criteria would be helpful. Thus
> > > > > > 
> > > > > > B) Sum up the ids of all tracks => Y So given same X, then
> > > > > > choose minimal Y as the base rotation.
> > > > > > 
> > > > > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and
> > > > > > from
> > > > > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2
> > > > > > and from
> > > > > > id=2 to id=4 thus Y=8.
> > > > > > 
> > > > > > C) What about tiles with stations on it? If you have only one
> > > > > > station which is connected to all tracks you can easily rely on
> > > 
> > > ranking by X:
> > > > > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > > > > > 
> > > > > > If you have two stations the minimal rotation is always found by
> > > > > > ranking with X and Y as long as the stations have identical
> > > > > > attributes and number of tracks.
> > > > > > 
> > > > > > However in other cases it can get more difficult and one still
> > > > > > has to fall back to some base rotation defined in the master
> 
> database.
> 
> > > > > > (One Example is tile 11 in
> > 
> > http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > 
> > > > > m
> > > > > 
> > > > > > ). Facing 1, 3 and 5 have same X and Y.
> > > > > > 
> > > > > > Related to this is he issue of symmetry: For example tile 9 has
> > > > > > a potential facing 4 (which is the rotation by 180 degree, but
> > > > > > as tile
> > > > > > 9 has exactly a symmetry there, this facing can ignored). So
> > > > > > identity in X and Y is a necessary condition for symmetry. For
> > > > > > the
> > > > > > 1830 tile set it is also a sufficient condition (as far as I
> > > > > > have checked, correct me if I am wrong)
> > > > > > 
> > > > > > In general the identity of X and Y is not a sufficient condition
> > > > > > for all
> > > > > > (existing) 18xx tiles (see example above) and if someone
> > > > > > proposes an algorithm that covers more cases than mine I would be
> > 
> > very grateful.
> > 
> > > > > > But for my case (an efficient algorithm) a necessary condition
> > > > > > that is easy to calculate is already very helpful as the more
> > > > > > complex check is only needed for those cases not eliminated by
> > > > > > the simple one (similar to a hash code to test equality).
> > > > > > 
> > > > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > > > > >> The currently ongoing discussion in the [18xx] group on how to
> > > > > >> describe tile lays is also of interest for Rails.  I'm in
> > > > > >> particular referring to cases where the Rails (TileDesigner)
> > > > > >> tile orientation (i.e., the tile number placement)  is
> > > > > >> different from the physical game. I just checked
> > > > > >> 1830 and 1856. The 1830 tile orientations are the same as in
> > > > > >> Rails (except tile #65), whereas with 1856 there are many
> > 
> > differences.
> > 
> > > > > >> Take tile #23 as an example. The 1856 orientation of this tile
> > > > > >> is upside-down as compared with 1830 and Rails.  Now assume
> > > > > >> tile #9 has been laid before on hex O10 (connecting SW-NE) and
> > > > > >> is upgraded to tile #23 (adding a connection NW-NE).  Now the
> > > > > >> question is: how to display this upgrade in the map window and
> 
> the
> 
> > game report?
> > 
> > > > > >> The Rails tile has the number as in 1830, on the SW side in
> > > > > >> this case, so the upgrade is now coded as #23/O10/SW.  However,
> > > > > >> the physical tile would have its number on the NE side, so in
> > > > > >> an FTF game the upgrade would be denoted as #23/O10/NE.
> > > > > >> 
> > > > > >> My question is: what do we prefer?
> > > > > >> 
> > > > > >> I am thinking on adding an optional attribute to <Tile> in
> > > > > >> TileSet.xml that specifies the 'base rotation' of the physical
> > > > > >> tile as compared with the Rails tile (or vice versa). This
> > > > > >> 'base rotation' would then be added (or
> > > > > >> subtracted) to the internal value to calculate the displayed
> > > > > >> tile orientation.
> > > > > >> 
> > > > > >> So, to make the laid tile in this example be described as
> > > > > >> #23/O10/NE we should add an attribute like 'baseRotation="3"'.
> > > > > >> 
> > > > > >> Any need for this feature? Should it  be an option?
> > > > > >> 
> > > > > >> Erik.
> > > > > >> 
> > > > > >> 
> > > > > >> ---------------------------------------------------------------
> > > > > >> ----
> > > > > >> --
> > > > > >> ------
> > > > > >> --- AppSumo Presents a FREE Video for the SourceForge Community
> > > > > >> by Eric Ries, the creator of the Lean Startup Methodology on
> > > > > >> "Lean Startup Secrets Revealed." This video shows you how to
> > > > > >> validate your ideas, optimize your ideas and identify your
> 
> business
> 
> > strategy.
> > 
> > > > > >> http://p.sf.net/sfu/appsumosfdev2dev
> > > > > >> _______________________________________________
> > > > > >> Rails-devel mailing list
> > > > > >> Rai...@li...
> > > > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > > > 
> > > > > > ----------------------------------------------------------------
> > > > > > ----
> > > > > > --
> > > > > > -------- AppSumo Presents a FREE Video for the SourceForge
> > > > > > Community by Eric Ries, the creator of the Lean Startup
> > > > > > Methodology on "Lean Startup Secrets Revealed." This video shows
> > > > > > you how to validate your ideas, optimize your ideas and identify
> 
> your
> 
> > business strategy.
> > 
> > > > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > > > _______________________________________________
> > > > > > Rails-devel mailing list
> > > > > > Rai...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > -
> > > 
> > > > --
> > > > 
> > > > > AppSumo Presents a FREE Video for the SourceForge Community by
> > > > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > > Startup Secrets Revealed." This video shows you how to validate
> > > > > your ideas, optimize your ideas and identify your business
> > > > > strategy. http://p.sf.net/sfu/appsumosfdev2dev
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > - --
> > > 
> > > > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > > > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > > > Secrets Revealed." This video shows you how to validate your ideas,
> > > > optimize your ideas and identify your business strategy.
> > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- AppSumo Presents a FREE Video for the SourceForge Community by
> > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > Startup Secrets Revealed." This video shows you how to validate your
> > > ideas, optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.4.2

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

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> 
> These problems still exist.
> 
> 3. When the 4+4 train is purchased (after the Prussian has formed), all
> players get asked whether to convert our remaining minors.  (This is only
> supposed to happen (a) when the M2 converts, thus forming the Prussian, or
> (b) at the beginnings of rounds.  Thus we should not be asked upon the 4+4
> purchase unless the owner of M2 declined all earlier opportunities to form
> the Prussian and so is forced to form it then.)

Confirmed, will be fixed.
 
> 5. The train limit for most major companies gets reduced to two, and I am
> forced to discard one, upon the 4+4-train purchase.  This is not supposed
to
> happen until the first 5-train purchase.

Conformed, this is a configuration issue that will be fixed with the new
phase management approach.

> 6. When I was forced to purchase a train using money out of hand, the
> program forced me to buy the 3 from the bank pool rather than the 6 which
> is the next new train for sale.  I believe I am supposed to be allowed to
buy
> the 6-train.

Indeed. This relates to another problem with 1856, reported by Aliza Panitz
months ago:

> However, a play-forward of a game I'm in has Rails telling a company
> president that they may contribute cash up to the face value of the train
in
> question when making a forced purchase from another company.

1835 behaves the same way. It's a generic problem: all games still follow
the emergency train buying rules of 1830.  That obviously needs to be
addressed.

Erik.

Re: [Rails-devel] Tile orientation display

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

Stefan,

Thanks for the clarification (I didn't find it irritating, but missed the
background).

About the "natural" tile orientation: there has been a similar discussion in
the [18xx] group a few months ago.  See message #31521, where Scott pointed
to John Tamplin's "canonical orientation" and Steve Thomas commented upon
that.  Could it be beneficial to align with that proposal?

The trouble with any standard tile orientation that is different from the
usual ones (with the number at S or SW), is that it is meaningless to anyone
who has not internalized the algorithm to define it (and I would have
trouble doing that).  To fix that, we would need to change all tile
rotations in TileDesigner to align with the new rule.  That's not
impossible, but a lot of work...

I hope I'm still understanding you right...

Erik.
 

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 14, 2011 7:38 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tile orientation display
> 
> Edward & Erik,
> 
> sorry for the (irritating) mail: Erik guessed right, this was a  copy from
a more
> extended document about my thoughts to create the complete logic for tile
> laying and upgrading. This would prevent any illegal tile-lay and thus
needs to
> consider the various upgrade rules (permissive, semi-restrictive and
> restrictive) and cope with all the little details the human mind can
easily
> solve, but are difficult for an algorithm.
> 
> This is not yet finished as I am not satisfied with neither the text nor
the
> proposed design. And it would require a substantial rewrote of the UI,
which
> I would delay until it is decided which client/server model and what kind
of
> (mobile) devices Rails will support in the future.
> 
> However what I proposed below is a (very simple) rule to create a natural
> orientation of each tile, which is only defined by the actual track
> configuration of the tile. This avoids arbitrary rules like the location
of tile id,
> which result in different orientations of the same tile between different
18xx
> titles (or even inside one game as reported on the yahoo list).
> 
> Another advantage is that allows someone to redraw/redesign the artwork
> of the tile and then the algorithm would still define the same base
rotation.
> 
> Other than this the rule makes my (yet unpublished) algorithm to choose
the
> allowed upgrade rotations more efficient and is part of the problem to
> identify symmetric orientations (there are only 3 possible orientations
for the
> straight line, not 6). But that part was impossible to understand without
the
> context.
> 
> Stefan
> 
> 
> On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote:
> > Thinking about it (I should do that more often :-), Stefan is probably
> > working on making the rotation logic route-aware (as in: "some new
> > track must be part of a valid route" and all its variations). The
> > current code isn't.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Erik Vos [mailto:eri...@xs...]
> > > Sent: Wednesday, July 13, 2011 10:02 AM
> > > To: 'Development list for Rails: an 18xx game'
> > > Subject: Re: [Rails-devel] Tile orientation display
> > >
> > > > -----Original Message-----
> > > > From: Edward S. Rustin [mailto:ed...@we...]
> > > >
> > > > Having read all that, I do have to wonder about one thing - what's
> > > > the problem you're trying to solve?
> > >
> > > That also was my first question. I can imagine that some clever
> > > algorithm would make it easier to determine the valid rotations of a
laid
> tile.
> > > Currently that's pretty messy code of my making (see
> > > GUITile.rotate()),
> >
> > and
> >
> > > if Stefan sees ways to improve/simplify that, I'm all for it.
> > >
> > > Unfortunately, I don't yet see how Stefan's calculations would
> > > improve the situation, so I can't provide any more substantial
> commentary.
> > >
> > > The allowed rotations of tiles #64-68 (the tile #59 upgrades) were
> > > hardest
> >
> > to
> >
> > > get right, so that's a main test case.
> > >
> > > > It might just be my lack of knowledge about Rails (although I've
> > > > been
> > >
> > > picking
> > >
> > > > some up here and there from lurking on here and prodding the
> > > > source), but I'm really not sure what the purpose of your
> > > > algorithm is. Surely for any
> > >
> > > given
> > >
> > > > 18xx game, there's a specified upgrade path where Tile X can be
> > > > upgraded
> > >
> > > to
> > >
> > > > Tile Y or Tile Z, and there's only going to be a few unique
> > > > mappings based
> > >
> > > on
> > >
> > > > orientation.
> > > >
> > > > As a side point, your algorithm might work better were you to
> > > > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit
> > > > binary
> > > > value) so that you avoid the problem of two different tiles having
> > > > the
> > >
> > > same
> > >
> > > > value (a tile with exits at 1, 2, 5 has the same value as one with
> > > > exits
> > >
> > > at 1, 3, 4
> > >
> > > > for example).
> > >
> > > Another side point: as we currently use S/SW=0, wouldn't it be less
> >
> > confusing
> >
> > > to stick with that start point for side numbering? Or doesn't it
> > > make a difference?
> > >
> > > > On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...>
> wrote:
> > > > > Somehow related to the discussion and I would be happy to hear
> > > > > suggestions and comments on that problem:
> > > > >
> > > > > After finishing the RevenueCalculation algorithms I started to
> > > > > design/outline the workflow of an UpgradeTile algorithm.
> > > > >
> > > > > To make this efficient I intended to make the base rotation of
> > > > > all tiles such that it allows the upgrades to fit with minimal
rotations.
> > > > >
> > > > > What is the idea behind this? Take the example how Keith
> > > > > Thomasson built his tile sheets for postal play.
> > > > >
> > > > > Check the tile sheet of:
> > > > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > > > It seems that in many cases those tiles are already orientated
> > > > > to allow for easy upgrades:
> > > > >
> > > > > Define Facing 1 as the base rotation of an tile. Then it is the
> > > > > case for example for an upgrade from tile 8 to tiles 19, 24, 29
> > > > > the possible upgrade will keep facings identical (thus no
> > > > > rotation of the upgraded tiles is required). To upgrade to tile
> > > > > 16 and 25 one of the possible upgrades has identical facings.
> > > > >
> > > > > So I came up with the idea if there is a solution that allows to
> > > > > define an algorithm that defines a base rotations for all tiles
> > > > > such that upgrades can be done with only a few rotations.
> > > > >
> > > > > At that time my idea was the following:
> > > > > Id each hex side (for the example start with NW = 0, NE = 1, ...
> > > > > , W =
> > > > > 5)
> > > > >
> > > > > A) Then sum up the id of all sides with at least one track
> > > > > leading to it. Call that X. Compare each possible facing and
> > > > > choose that with minimal X as the base rotation.
> > > > >
> > > > > It is easy to check that tiles 7, 8 and 9 are optimal rotated
> > > > > given in that definition (and starting id=0 from NW).
> > > > >
> > > > > It is also the case for 16, 18, 19. However not for 20 (facing 2
> > > > > has minimal ids), and 23 (here facing 4), but again for 24.
> > > > >
> > > > > For tile 25 facing 1 and 3 have the same X. So a secondary
> > > > > criteria would be helpful. Thus
> > > > >
> > > > > B) Sum up the ids of all tracks => Y So given same X, then
> > > > > choose minimal Y as the base rotation.
> > > > >
> > > > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and
> > > > > from
> > > > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2
> > > > > and from
> > > > > id=2 to id=4 thus Y=8.
> > > > >
> > > > > C) What about tiles with stations on it? If you have only one
> > > > > station which is connected to all tracks you can easily rely on
> >
> > ranking by X:
> > > > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > > > >
> > > > > If you have two stations the minimal rotation is always found by
> > > > > ranking with X and Y as long as the stations have identical
> > > > > attributes and number of tracks.
> > > > >
> > > > > However in other cases it can get more difficult and one still
> > > > > has to fall back to some base rotation defined in the master
database.
> > > > > (One Example is tile 11 in
> > >
> > >
> http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > >
> > > > m
> > > >
> > > > > ). Facing 1, 3 and 5 have same X and Y.
> > > > >
> > > > > Related to this is he issue of symmetry: For example tile 9 has
> > > > > a potential facing 4 (which is the rotation by 180 degree, but
> > > > > as tile
> > > > > 9 has exactly a symmetry there, this facing can ignored). So
> > > > > identity in X and Y is a necessary condition for symmetry. For
> > > > > the
> > > > > 1830 tile set it is also a sufficient condition (as far as I
> > > > > have checked, correct me if I am wrong)
> > > > >
> > > > > In general the identity of X and Y is not a sufficient condition
> > > > > for all
> > > > > (existing) 18xx tiles (see example above) and if someone
> > > > > proposes an algorithm that covers more cases than mine I would be
> very grateful.
> > > > >
> > > > > But for my case (an efficient algorithm) a necessary condition
> > > > > that is easy to calculate is already very helpful as the more
> > > > > complex check is only needed for those cases not eliminated by
> > > > > the simple one (similar to a hash code to test equality).
> > > > >
> > > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > > > >> The currently ongoing discussion in the [18xx] group on how to
> > > > >> describe tile lays is also of interest for Rails.  I'm in
> > > > >> particular referring to cases where the Rails (TileDesigner)
> > > > >> tile orientation (i.e., the tile number placement)  is
> > > > >> different from the physical game. I just checked
> > > > >> 1830 and 1856. The 1830 tile orientations are the same as in
> > > > >> Rails (except tile #65), whereas with 1856 there are many
> differences.
> > > > >>
> > > > >> Take tile #23 as an example. The 1856 orientation of this tile
> > > > >> is upside-down as compared with 1830 and Rails.  Now assume
> > > > >> tile #9 has been laid before on hex O10 (connecting SW-NE) and
> > > > >> is upgraded to tile #23 (adding a connection NW-NE).  Now the
> > > > >> question is: how to display this upgrade in the map window and
the
> game report?
> > > > >>
> > > > >> The Rails tile has the number as in 1830, on the SW side in
> > > > >> this case, so the upgrade is now coded as #23/O10/SW.  However,
> > > > >> the physical tile would have its number on the NE side, so in
> > > > >> an FTF game the upgrade would be denoted as #23/O10/NE.
> > > > >>
> > > > >> My question is: what do we prefer?
> > > > >>
> > > > >> I am thinking on adding an optional attribute to <Tile> in
> > > > >> TileSet.xml that specifies the 'base rotation' of the physical
> > > > >> tile as compared with the Rails tile (or vice versa). This
> > > > >> 'base rotation' would then be added (or
> > > > >> subtracted) to the internal value to calculate the displayed
> > > > >> tile orientation.
> > > > >>
> > > > >> So, to make the laid tile in this example be described as
> > > > >> #23/O10/NE we should add an attribute like 'baseRotation="3"'.
> > > > >>
> > > > >> Any need for this feature? Should it  be an option?
> > > > >>
> > > > >> Erik.
> > > > >>
> > > > >>
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> --
> > > > >> ------
> > > > >> --- AppSumo Presents a FREE Video for the SourceForge Community
> > > > >> by Eric Ries, the creator of the Lean Startup Methodology on
> > > > >> "Lean Startup Secrets Revealed." This video shows you how to
> > > > >> validate your ideas, optimize your ideas and identify your
business
> strategy.
> > > > >> http://p.sf.net/sfu/appsumosfdev2dev
> > > > >> _______________________________________________
> > > > >> Rails-devel mailing list
> > > > >> Rai...@li...
> > > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > -------- AppSumo Presents a FREE Video for the SourceForge
> > > > > Community by Eric Ries, the creator of the Lean Startup
> > > > > Methodology on "Lean Startup Secrets Revealed." This video shows
> > > > > you how to validate your ideas, optimize your ideas and identify
your
> business strategy.
> > > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > -
> >
> > > --
> > >
> > > > AppSumo Presents a FREE Video for the SourceForge Community by
> > > > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > Startup Secrets Revealed." This video shows you how to validate
> > > > your ideas, optimize your ideas and identify your business strategy.
> > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > > Secrets Revealed." This video shows you how to validate your ideas,
> > > optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- AppSumo Presents a FREE Video for the SourceForge Community by
> > Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > Startup Secrets Revealed." This video shows you how to validate your
> > ideas, optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Refactored loading code

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

This seems like duplication of work: The repository already keeps a history of 
the change-logs. I believe it will be the same for git. Thus I am reluctant to 
copy the logs into the wiki manually.

What I think would be helpful (and I did that once already) to attach the 
revision number after the e-mail accompanying the commit (if there is any).
In combination with blame this would really help to find out, what was the 
idea behind the change. I quite often search the Rails archive for more info 
of a change.

I have not checked if there is a revision number of the sf-git repository and 
potentially it might be better to copy the main parts of the e-mail into  
(additional) javadoc document(s).

Instead of adding the history of development to the wiki I suggest to add a 
development roadmap/todo-list to the wiki.
Especially with local repositories it gets more likely that several people are 
working on the same stuff, which is both a waste of resources and makes code 
merging difficult. And it might even attract new people, if they know where to 
start and what is needed.

Stefan



> 
> As you may or may not have noticed, since some time I'm pretty meticulously
> creating entries in the Wiki Change Log for all my commits (except very
> trivial ones).  I don't know if I can expect the same from Brett and you
> (as we have seen earlier today, I'm not really the right person to request
> discipline). In any case, I have just created simple entries for the
> recent commits 1602-1604 by the two of you.  Feel free to  correct or
> expand.
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > Verzonden: dinsdag 5 juli 2011 19:11
> > Aan: 'Development list for Rails: an 18xx game'
> > Onderwerp: [Rails-devel] Refactored loading code
> > 
> > Brett & Erik,
> > some time ago I started to refactor the game loading code in one class to
> 
> get
> 
> > the ListAndFixSavedFiles utility adjusted to the new comments.
> > 
> > To avoid more incompatibilities from the started refactoring from Brett
> 
> now I
> 
> > thought to adjust the code to include the new reload functionality of
> > Erik
> 
> to
> 
> > be able to commit those changes.
> > 
> > Nearly all loading functionality has been moved to a new GameLoader class
> 
> in
> 
> > rails.util package. The load function in Game, GameManager and
> > ListAndFixSavedFiles now all make use of a a GameLoader object.
> > 
> > I have also added a line to the reload error message that asks the user
> > to submit the corrupt save file to the Rails user list for bug tracking.
> > If
> 
> you think
> 
> > that is not a good idea, simply remove that text from
> > LocalisedProperties.
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> - --
> 
> > All of the data generated in your IT infrastructure is seriously
> > valuable. Why? It contains a definitive record of application
> > performance, security threats, fraudulent activity, and more. Splunk
> > takes this data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tile orientation display

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

Edward & Erik,

sorry for the (irritating) mail: Erik guessed right, this was a  copy from a 
more extended document about my thoughts to create the complete logic for tile 
laying and upgrading. This would prevent any illegal tile-lay and thus needs 
to consider the various upgrade rules (permissive, semi-restrictive and 
restrictive) and cope with all the little details the human mind can easily 
solve, but are difficult for an algorithm.

This is not yet finished as I am not satisfied with neither the text nor the 
proposed design. And it would require a substantial rewrote of the UI, which I 
would delay until it is decided which client/server model and what kind of 
(mobile) devices Rails will support in the future.

However what I proposed below is a (very simple) rule to create a natural 
orientation of each tile, which is only defined by the actual track 
configuration of the tile. This avoids arbitrary rules like the location of 
tile id, which result in different orientations of the same tile between 
different 18xx titles (or even inside one game as reported on the yahoo list).

Another advantage is that allows someone to redraw/redesign the artwork of the 
tile and then the algorithm would still define the same base rotation.

Other than this the rule makes my (yet unpublished) algorithm to choose the 
allowed upgrade rotations more efficient and is part of the problem to 
identify symmetric orientations (there are only 3 possible orientations for 
the straight line, not 6). But that part was impossible to understand without 
the context.

Stefan


On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote:
> Thinking about it (I should do that more often :-), Stefan is probably
> working on making the rotation logic route-aware (as in: "some new track
> must be part of a valid route" and all its variations). The current code
> isn't.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Wednesday, July 13, 2011 10:02 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Tile orientation display
> > 
> > > -----Original Message-----
> > > From: Edward S. Rustin [mailto:ed...@we...]
> > > 
> > > Having read all that, I do have to wonder about one thing - what's the
> > > problem you're trying to solve?
> > 
> > That also was my first question. I can imagine that some clever algorithm
> > would make it easier to determine the valid rotations of a laid tile.
> > Currently that's pretty messy code of my making (see GUITile.rotate()),
> 
> and
> 
> > if Stefan sees ways to improve/simplify that, I'm all for it.
> > 
> > Unfortunately, I don't yet see how Stefan's calculations would improve
> > the situation, so I can't provide any more substantial commentary.
> > 
> > The allowed rotations of tiles #64-68 (the tile #59 upgrades) were
> > hardest
> 
> to
> 
> > get right, so that's a main test case.
> > 
> > > It might just be my lack of knowledge about Rails (although I've been
> > 
> > picking
> > 
> > > some up here and there from lurking on here and prodding the source),
> > > but I'm really not sure what the purpose of your algorithm is. Surely
> > > for any
> > 
> > given
> > 
> > > 18xx game, there's a specified upgrade path where Tile X can be
> > > upgraded
> > 
> > to
> > 
> > > Tile Y or Tile Z, and there's only going to be a few unique mappings
> > > based
> > 
> > on
> > 
> > > orientation.
> > > 
> > > As a side point, your algorithm might work better were you to
> > > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit binary
> > > value) so that you avoid the problem of two different tiles having the
> > 
> > same
> > 
> > > value (a tile with exits at 1, 2, 5 has the same value as one with
> > > exits
> > 
> > at 1, 3, 4
> > 
> > > for example).
> > 
> > Another side point: as we currently use S/SW=0, wouldn't it be less
> 
> confusing
> 
> > to stick with that start point for side numbering? Or doesn't it make a
> > difference?
> > 
> > > On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...> wrote:
> > > > Somehow related to the discussion and I would be happy to hear
> > > > suggestions and comments on that problem:
> > > > 
> > > > After finishing the RevenueCalculation algorithms I started to
> > > > design/outline the workflow of an UpgradeTile algorithm.
> > > > 
> > > > To make this efficient I intended to make the base rotation of all
> > > > tiles such that it allows the upgrades to fit with minimal rotations.
> > > > 
> > > > What is the idea behind this? Take the example how Keith Thomasson
> > > > built his tile sheets for postal play.
> > > > 
> > > > Check the tile sheet of:
> > > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > > It seems that in many cases those tiles are already orientated to
> > > > allow for easy upgrades:
> > > > 
> > > > Define Facing 1 as the base rotation of an tile. Then it is the case
> > > > for example for an upgrade from tile 8 to tiles 19, 24, 29 the
> > > > possible upgrade will keep facings identical (thus no rotation of
> > > > the upgraded tiles is required). To upgrade to tile 16 and 25 one of
> > > > the possible upgrades has identical facings.
> > > > 
> > > > So I came up with the idea if there is a solution that allows to
> > > > define an algorithm that defines a base rotations for all tiles such
> > > > that upgrades can be done with only a few rotations.
> > > > 
> > > > At that time my idea was the following:
> > > > Id each hex side (for the example start with NW = 0, NE = 1, ... , W
> > > > =
> > > > 5)
> > > > 
> > > > A) Then sum up the id of all sides with at least one track leading
> > > > to it. Call that X. Compare each possible facing and choose that
> > > > with minimal X as the base rotation.
> > > > 
> > > > It is easy to check that tiles 7, 8 and 9 are optimal rotated given
> > > > in that definition (and starting id=0 from NW).
> > > > 
> > > > It is also the case for 16, 18, 19. However not for 20 (facing 2 has
> > > > minimal ids), and 23 (here facing 4), but again for 24.
> > > > 
> > > > For tile 25 facing 1 and 3 have the same X. So a secondary criteria
> > > > would be helpful. Thus
> > > > 
> > > > B) Sum up the ids of all tracks => Y So given same X, then choose
> > > > minimal Y as the base rotation.
> > > > 
> > > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and from
> > > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2 and
> > > > from
> > > > id=2 to id=4 thus Y=8.
> > > > 
> > > > C) What about tiles with stations on it? If you have only one
> > > > station which is connected to all tracks you can easily rely on
> 
> ranking by X:
> > > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > > > 
> > > > If you have two stations the minimal rotation is always found by
> > > > ranking with X and Y as long as the stations have identical
> > > > attributes and number of tracks.
> > > > 
> > > > However in other cases it can get more difficult and one still has
> > > > to fall back to some base rotation defined in the master database.
> > > > (One Example is tile 11 in
> > 
> > http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > 
> > > m
> > > 
> > > > ). Facing 1, 3 and 5 have same X and Y.
> > > > 
> > > > Related to this is he issue of symmetry: For example tile 9 has a
> > > > potential facing 4 (which is the rotation by 180 degree, but as tile
> > > > 9 has exactly a symmetry there, this facing can ignored). So
> > > > identity in X and Y is a necessary condition for symmetry. For the
> > > > 1830 tile set it is also a sufficient condition (as far as I have
> > > > checked, correct me if I am wrong)
> > > > 
> > > > In general the identity of X and Y is not a sufficient condition for
> > > > all
> > > > (existing) 18xx tiles (see example above) and if someone proposes an
> > > > algorithm that covers more cases than mine I would be very grateful.
> > > > 
> > > > But for my case (an efficient algorithm) a necessary condition that
> > > > is easy to calculate is already very helpful as the more complex
> > > > check is only needed for those cases not eliminated by the simple
> > > > one (similar to a hash code to test equality).
> > > > 
> > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > > >> The currently ongoing discussion in the [18xx] group on how to
> > > >> describe tile lays is also of interest for Rails.  I'm in
> > > >> particular referring to cases where the Rails (TileDesigner) tile
> > > >> orientation (i.e., the tile number placement)  is different from
> > > >> the physical game. I just checked
> > > >> 1830 and 1856. The 1830 tile orientations are the same as in Rails
> > > >> (except tile #65), whereas with 1856 there are many differences.
> > > >> 
> > > >> Take tile #23 as an example. The 1856 orientation of this tile is
> > > >> upside-down as compared with 1830 and Rails.  Now assume tile #9
> > > >> has been laid before on hex O10 (connecting SW-NE) and is upgraded
> > > >> to tile #23 (adding a connection NW-NE).  Now the question is: how
> > > >> to display this upgrade in the map window and the game report?
> > > >> 
> > > >> The Rails tile has the number as in 1830, on the SW side in this
> > > >> case, so the upgrade is now coded as #23/O10/SW.  However, the
> > > >> physical tile would have its number on the NE side, so in an FTF
> > > >> game the upgrade would be denoted as #23/O10/NE.
> > > >> 
> > > >> My question is: what do we prefer?
> > > >> 
> > > >> I am thinking on adding an optional attribute to <Tile> in
> > > >> TileSet.xml that specifies the 'base rotation' of the physical tile
> > > >> as compared with the Rails tile (or vice versa). This 'base
> > > >> rotation' would then be added (or
> > > >> subtracted) to the internal value to calculate the displayed tile
> > > >> orientation.
> > > >> 
> > > >> So, to make the laid tile in this example be described as
> > > >> #23/O10/NE we should add an attribute like 'baseRotation="3"'.
> > > >> 
> > > >> Any need for this feature? Should it  be an option?
> > > >> 
> > > >> Erik.
> > > >> 
> > > >> 
> > > >> -------------------------------------------------------------------
> > > >> --
> > > >> ------
> > > >> --- AppSumo Presents a FREE Video for the SourceForge Community by
> > > >> Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > >> Startup Secrets Revealed." This video shows you how to validate
> > > >> your ideas, optimize your ideas and identify your business strategy.
> > > >> http://p.sf.net/sfu/appsumosfdev2dev
> > > >> _______________________________________________
> > > >> Rails-devel mailing list
> > > >> Rai...@li...
> > > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > 
> > > > --------------------------------------------------------------------
> > > > --
> > > > -------- AppSumo Presents a FREE Video for the SourceForge Community
> > > > by Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > > Startup Secrets Revealed." This video shows you how to validate your
> > > > ideas, optimize your ideas and identify your business strategy.
> > > > http://p.sf.net/sfu/appsumosfdev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> -
> 
> > --
> > 
> > > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > > Secrets Revealed." This video shows you how to validate your ideas,
> > > optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.4.2

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

Last year there were still some bugs related to issue 4 (buying/selling 
certificates of PR). I do not think they are not all fixed, Erik?

On my to-do-list there is a re-factoring of the code that deal with 
certificate limits and/or director change as this code is spread 
around/duplicated at several places and then the Prussian cases should be 
dealt with.

Note: If someone else does such a test game (which is a great help), a save 
file from the game end is the best. Given that is possible to jump at any 
point of the game via the Game Report window all earlier bugs can be 
recreated.

And in addition the test game can be added to the automated testing.
(At least after Brett fixed the issues that currently prevent testing ;-).

Stefan


On Wednesday, July 13, 2011 10:56:22 am Erik Vos wrote:
> Thanks for this (I believe third) 1835 playtest report.  I will look at the
> reported bugs 3, 5, 6 - did you perhaps save the game at those points? 
> Bugs always get fixed a lot faster if I don't have to reconstruct problem
> cases myself.  I will also think about your UI suggestions.
> 
> Erik.
> 
> > -----Original Message-----
> > From: John David Galt [mailto:jd...@di...]
> > Sent: Wednesday, July 13, 2011 7:32 AM
> > To: rai...@li...
> > Subject: [Rails-devel] 1835 playtest report - Rails 1.4.2
> > 
> > Most of the bugs I found in earlier versions are now gone, and I was able
> 
> to
> 
> > play the game through to the end.
> > 
> > These problems still exist.
> > 
> > 1. Map still doesn't show which cities are "Y" or "XX".
> > 
> > 2. During and after the starting round, it would be helpful to see what
> > percentage of the Prussian each player holds (that is, including shares
> 
> they
> 
> > will eventually receive in exchange for privates/minors now owned).
> > I suggest this be shown in (parentheses) in the Pr row of the table.
> > 
> > 3. When the 4+4 train is purchased (after the Prussian has formed), all
> > players get asked whether to convert our remaining minors.  (This is only
> > supposed to happen (a) when the M2 converts, thus forming the Prussian,
> > or (b) at the beginnings of rounds.  Thus we should not be asked upon
> > the 4+4 purchase unless the owner of M2 declined all earlier
> > opportunities to form the Prussian and so is forced to form it then.)
> > 
> > 4. While I haven't exhaustively tested the different combinations of
> 
> buying
> 
> > and selling certificates in companies that have more than one size, the
> > obvious bugs there appear fixed.  However, the display still does not
> > show which certificates each player has (and it's often important to
> > know, especially if you're considering nationalizing the big one).  I
> > suggest a
> 
> tooltip
> 
> > showing this information when you hover over that player's holding.
> > 
> > 5. The train limit for most major companies gets reduced to two, and I am
> > forced to discard one, upon the 4+4-train purchase.  This is not supposed
> 
> to
> 
> > happen until the first 5-train purchase.
> > 
> > 6. When I was forced to purchase a train using money out of hand, the
> > program forced me to buy the 3 from the bank pool rather than the 6 which
> > is the next new train for sale.  I believe I am supposed to be allowed to
> 
> buy
> 
> > the 6-train.
> 
> ---------------------------------------------------------------------------
> - --
> 
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.4.2

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

On 2011-07-13 01:56, Erik Vos wrote:
> Thanks for this (I believe third) 1835 playtest report.  I will look at the
> reported bugs 3, 5, 6 - did you perhaps save the game at those points?  Bugs
> always get fixed a lot faster if I don't have to reconstruct problem cases
> myself.  I will also think about your UI suggestions.

I saved the game once, about the time of bug 5.  Here it is (and I've copied
you in case the list filters it out).

Re: [Rails-devel] Tile orientation display

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

To summarize: the developers think it's a good idea, but the "real users" (if I may say so) don't really see a need for it.  So I suppose I will end up resting my case.

Indeed implementation would be very easy. The hard work is in comparing all tiles of all games with the Rails standard and update the XML for any differences found.  I would certainly not start doing that all on my own! 

The display options could be like (showing the result for the below example case):
- Rails (default)   #23/O10/SW
- Game   #23/O10/NE
- Rails[Game]   #23/O10/SW[NE]
But, as said, if interest remains as low as it is, I'll drop it.

Last call.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Tuesday, July 12, 2011 8:37 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tile orientation display
> 
> If it's as easy as specifying the starting rotation in the XML, that shouldn't be
> too cumbersome and appears to be a usability win (for users mapping the
> physical game to the digital game).
> 
> It sounds useful to me. :)
> 
> ---Brett.
> 
> 
> 
> On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> wrote:
> > The currently ongoing discussion in the [18xx] group on how to
> > describe tile lays is also of interest for Rails.  I'm in particular
> > referring to cases where the Rails (TileDesigner) tile orientation
> > (i.e., the tile number
> > placement)  is different from the physical game. I just checked 1830
> > and 1856. The 1830 tile orientations are the same as in Rails (except
> > tile #65), whereas with 1856 there are many differences.
> >
> > Take tile #23 as an example. The 1856 orientation of this tile is
> > upside-down as compared with 1830 and Rails.  Now assume tile #9 has
> > been laid before on hex O10 (connecting SW-NE) and is upgraded to tile
> > #23 (adding a connection NW-NE).  Now the question is: how to display
> > this upgrade in the map window and the game report?
> >
> > The Rails tile has the number as in 1830, on the SW side in this case,
> > so the upgrade is now coded as #23/O10/SW.  However, the physical tile
> > would have its number on the NE side, so in an FTF game the upgrade
> > would be denoted as #23/O10/NE.
> >
> > My question is: what do we prefer?
> >
> > I am thinking on adding an optional attribute to <Tile> in TileSet.xml
> > that specifies the 'base rotation' of the physical tile as compared
> > with the Rails tile (or vice versa). This 'base rotation' would then
> > be added (or
> > subtracted) to the internal value to calculate the displayed tile
> > orientation.
> >
> > So, to make the laid tile in this example be described as #23/O10/NE
> > we should add an attribute like 'baseRotation="3"'.
> >
> > Any need for this feature? Should it  be an option?
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- AppSumo Presents a FREE Video for the SourceForge Community
> > by Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > Startup Secrets Revealed." This video shows you how to validate your
> > ideas, optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Live Game

[Scott P. <sc...@re...>]

I have been arranging live games (sometimes Rails, sometimes Vassal,
sometimes webcam) via this group:
http://groups.google.com/group/18xx-online

We are playing Rails 18GA at 8pm CDT tonight (in about 9.5 hours).  If
anyone wants to join or observe, let me know.  We use Dropbox to send files
and Skype for voice chat.  I can help you get up to speed if you need.

Scott

Re: [Rails-devel] [Rails-users] Fwd: 1830 Reading & Coalfields Variant (Erik Vos)

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

This problem has been fixed. In this particular case, the THB home hex was
not laid, and that blocked further actions. 

 

Erik.

 

From: HJH Tigelaar [mailto:tig...@ya...] 
Sent: Monday, June 13, 2011 3:03 PM
To: rai...@li...
Subject: Re: [Rails-users] Fwd: 1830 Reading & Coalfields Variant (Erik Vos)

 

Hello Erik,

 

Following the users-digest, I noticed your solution for the Reading &
Coalfields variant problem. I also have a hangup with 1856. The CV posted a
station-marker in the THB hex earlier in the game. Now the THB wants to
operate for the first time, but it hangs up on that particular action.

I am attaching the save game.

 

Hildebrand

Re: [Rails-devel] Tile orientation display

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

Thinking about it (I should do that more often :-), Stefan is probably
working on making the rotation logic route-aware (as in: "some new track
must be part of a valid route" and all its variations). The current code
isn't.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday, July 13, 2011 10:02 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Tile orientation display
> 
> > -----Original Message-----
> > From: Edward S. Rustin [mailto:ed...@we...]
> >
> > Having read all that, I do have to wonder about one thing - what's the
> > problem you're trying to solve?
> 
> That also was my first question. I can imagine that some clever algorithm
> would make it easier to determine the valid rotations of a laid tile.
> Currently that's pretty messy code of my making (see GUITile.rotate()),
and
> if Stefan sees ways to improve/simplify that, I'm all for it.
> 
> Unfortunately, I don't yet see how Stefan's calculations would improve the
> situation, so I can't provide any more substantial commentary.
> 
> The allowed rotations of tiles #64-68 (the tile #59 upgrades) were hardest
to
> get right, so that's a main test case.
> 
> > It might just be my lack of knowledge about Rails (although I've been
> picking
> > some up here and there from lurking on here and prodding the source),
> > but I'm really not sure what the purpose of your algorithm is. Surely
> > for any
> given
> > 18xx game, there's a specified upgrade path where Tile X can be
> > upgraded
> to
> > Tile Y or Tile Z, and there's only going to be a few unique mappings
> > based
> on
> > orientation.
> >
> > As a side point, your algorithm might work better were you to
> > enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit binary
> > value) so that you avoid the problem of two different tiles having the
> same
> > value (a tile with exits at 1, 2, 5 has the same value as one with
> > exits
> at 1, 3, 4
> > for example).
> 
> Another side point: as we currently use S/SW=0, wouldn't it be less
confusing
> to stick with that start point for side numbering? Or doesn't it make a
> difference?
> 
> >
> > On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...> wrote:
> > > Somehow related to the discussion and I would be happy to hear
> > > suggestions and comments on that problem:
> > >
> > > After finishing the RevenueCalculation algorithms I started to
> > > design/outline the workflow of an UpgradeTile algorithm.
> > >
> > > To make this efficient I intended to make the base rotation of all
> > > tiles such that it allows the upgrades to fit with minimal rotations.
> > >
> > > What is the idea behind this? Take the example how Keith Thomasson
> > > built his tile sheets for postal play.
> > >
> > > Check the tile sheet of:
> > > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > > It seems that in many cases those tiles are already orientated to
> > > allow for easy upgrades:
> > >
> > > Define Facing 1 as the base rotation of an tile. Then it is the case
> > > for example for an upgrade from tile 8 to tiles 19, 24, 29 the
> > > possible upgrade will keep facings identical (thus no rotation of
> > > the upgraded tiles is required). To upgrade to tile 16 and 25 one of
> > > the possible upgrades has identical facings.
> > >
> > > So I came up with the idea if there is a solution that allows to
> > > define an algorithm that defines a base rotations for all tiles such
> > > that upgrades can be done with only a few rotations.
> > >
> > > At that time my idea was the following:
> > > Id each hex side (for the example start with NW = 0, NE = 1, ... , W
> > > =
> > > 5)
> > >
> > > A) Then sum up the id of all sides with at least one track leading
> > > to it. Call that X. Compare each possible facing and choose that
> > > with minimal X as the base rotation.
> > >
> > > It is easy to check that tiles 7, 8 and 9 are optimal rotated given
> > > in that definition (and starting id=0 from NW).
> > >
> > > It is also the case for 16, 18, 19. However not for 20 (facing 2 has
> > > minimal ids), and 23 (here facing 4), but again for 24.
> > >
> > > For tile 25 facing 1 and 3 have the same X. So a secondary criteria
> > > would be helpful. Thus
> > >
> > > B) Sum up the ids of all tracks => Y So given same X, then choose
> > > minimal Y as the base rotation.
> > >
> > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and from
> > > id=0 to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2 and
> > > from
> > > id=2 to id=4 thus Y=8.
> > >
> > > C) What about tiles with stations on it? If you have only one
> > > station which is connected to all tracks you can easily rely on
ranking by X:
> > > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> > >
> > > If you have two stations the minimal rotation is always found by
> > > ranking with X and Y as long as the stations have identical
> > > attributes and number of tracks.
> > >
> > > However in other cases it can get more difficult and one still has
> > > to fall back to some base rotation defined in the master database.
> > > (One Example is tile 11 in
> > >
> >
> http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> > m
> > > ). Facing 1, 3 and 5 have same X and Y.
> > >
> > > Related to this is he issue of symmetry: For example tile 9 has a
> > > potential facing 4 (which is the rotation by 180 degree, but as tile
> > > 9 has exactly a symmetry there, this facing can ignored). So
> > > identity in X and Y is a necessary condition for symmetry. For the
> > > 1830 tile set it is also a sufficient condition (as far as I have
> > > checked, correct me if I am wrong)
> > >
> > > In general the identity of X and Y is not a sufficient condition for
> > > all
> > > (existing) 18xx tiles (see example above) and if someone proposes an
> > > algorithm that covers more cases than mine I would be very grateful.
> > >
> > > But for my case (an efficient algorithm) a necessary condition that
> > > is easy to calculate is already very helpful as the more complex
> > > check is only needed for those cases not eliminated by the simple
> > > one (similar to a hash code to test equality).
> > >
> > >
> > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> > >> The currently ongoing discussion in the [18xx] group on how to
> > >> describe tile lays is also of interest for Rails.  I'm in
> > >> particular referring to cases where the Rails (TileDesigner) tile
> > >> orientation (i.e., the tile number placement)  is different from
> > >> the physical game. I just checked
> > >> 1830 and 1856. The 1830 tile orientations are the same as in Rails
> > >> (except tile #65), whereas with 1856 there are many differences.
> > >>
> > >> Take tile #23 as an example. The 1856 orientation of this tile is
> > >> upside-down as compared with 1830 and Rails.  Now assume tile #9
> > >> has been laid before on hex O10 (connecting SW-NE) and is upgraded
> > >> to tile #23 (adding a connection NW-NE).  Now the question is: how
> > >> to display this upgrade in the map window and the game report?
> > >>
> > >> The Rails tile has the number as in 1830, on the SW side in this
> > >> case, so the upgrade is now coded as #23/O10/SW.  However, the
> > >> physical tile would have its number on the NE side, so in an FTF
> > >> game the upgrade would be denoted as #23/O10/NE.
> > >>
> > >> My question is: what do we prefer?
> > >>
> > >> I am thinking on adding an optional attribute to <Tile> in
> > >> TileSet.xml that specifies the 'base rotation' of the physical tile
> > >> as compared with the Rails tile (or vice versa). This 'base rotation'
> > >> would then be added (or
> > >> subtracted) to the internal value to calculate the displayed tile
> > >> orientation.
> > >>
> > >> So, to make the laid tile in this example be described as
> > >> #23/O10/NE we should add an attribute like 'baseRotation="3"'.
> > >>
> > >> Any need for this feature? Should it  be an option?
> > >>
> > >> Erik.
> > >>
> > >>
> > >> -------------------------------------------------------------------
> > >> --
> > >> ------
> > >> --- AppSumo Presents a FREE Video for the SourceForge Community by
> > >> Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > >> Startup Secrets Revealed." This video shows you how to validate
> > >> your ideas, optimize your ideas and identify your business strategy.
> > >> http://p.sf.net/sfu/appsumosfdev2dev
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > > --------------------------------------------------------------------
> > > --
> > > -------- AppSumo Presents a FREE Video for the SourceForge Community
> > > by Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > > Startup Secrets Revealed." This video shows you how to validate your
> > > ideas, optimize your ideas and identify your business strategy.
> > > http://p.sf.net/sfu/appsumosfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> >
> >
>
----------------------------------------------------------------------------
> --
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.4.2

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

Thanks for this (I believe third) 1835 playtest report.  I will look at the
reported bugs 3, 5, 6 - did you perhaps save the game at those points?  Bugs
always get fixed a lot faster if I don't have to reconstruct problem cases
myself.  I will also think about your UI suggestions.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Wednesday, July 13, 2011 7:32 AM
> To: rai...@li...
> Subject: [Rails-devel] 1835 playtest report - Rails 1.4.2
> 
> Most of the bugs I found in earlier versions are now gone, and I was able
to
> play the game through to the end.
> 
> These problems still exist.
> 
> 1. Map still doesn't show which cities are "Y" or "XX".
> 
> 2. During and after the starting round, it would be helpful to see what
> percentage of the Prussian each player holds (that is, including shares
they
> will eventually receive in exchange for privates/minors now owned).
> I suggest this be shown in (parentheses) in the Pr row of the table.
> 
> 3. When the 4+4 train is purchased (after the Prussian has formed), all
> players get asked whether to convert our remaining minors.  (This is only
> supposed to happen (a) when the M2 converts, thus forming the Prussian, or
> (b) at the beginnings of rounds.  Thus we should not be asked upon the 4+4
> purchase unless the owner of M2 declined all earlier opportunities to form
> the Prussian and so is forced to form it then.)
> 
> 4. While I haven't exhaustively tested the different combinations of
buying
> and selling certificates in companies that have more than one size, the
> obvious bugs there appear fixed.  However, the display still does not show
> which certificates each player has (and it's often important to know,
> especially if you're considering nationalizing the big one).  I suggest a
tooltip
> showing this information when you hover over that player's holding.
> 
> 5. The train limit for most major companies gets reduced to two, and I am
> forced to discard one, upon the 4+4-train purchase.  This is not supposed
to
> happen until the first 5-train purchase.
> 
> 6. When I was forced to purchase a train using money out of hand, the
> program forced me to buy the 3 from the bank pool rather than the 6 which
> is the next new train for sale.  I believe I am supposed to be allowed to
buy
> the 6-train.
> 
>
----------------------------------------------------------------------------
--
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tile orientation display

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

> -----Original Message-----
> From: Edward S. Rustin [mailto:ed...@we...]
> 
> Having read all that, I do have to wonder about one thing - what's the
> problem you're trying to solve?

That also was my first question. I can imagine that some clever algorithm
would make it easier to determine the valid rotations of a laid tile.
Currently that's pretty messy code of my making (see GUITile.rotate()), and
if Stefan sees ways to improve/simplify that, I'm all for it. 

Unfortunately, I don't yet see how Stefan's calculations would improve the
situation, so I can't provide any more substantial commentary.

The allowed rotations of tiles #64-68 (the tile #59 upgrades) were hardest
to get right, so that's a main test case.

> It might just be my lack of knowledge about Rails (although I've been
picking
> some up here and there from lurking on here and prodding the source), but
> I'm really not sure what the purpose of your algorithm is. Surely for any
given
> 18xx game, there's a specified upgrade path where Tile X can be upgraded
to
> Tile Y or Tile Z, and there's only going to be a few unique mappings based
on
> orientation.
> 
> As a side point, your algorithm might work better were you to enumerate
> the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit binary
> value) so that you avoid the problem of two different tiles having the
same
> value (a tile with exits at 1, 2, 5 has the same value as one with exits
at 1, 3, 4
> for example).

Another side point: as we currently use S/SW=0, wouldn't it be less
confusing to stick with that start point for side numbering? Or doesn't it
make a difference?

> 
> On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...> wrote:
> > Somehow related to the discussion and I would be happy to hear
> > suggestions and comments on that problem:
> >
> > After finishing the RevenueCalculation algorithms I started to
> > design/outline the workflow of an UpgradeTile algorithm.
> >
> > To make this efficient I intended to make the base rotation of all
> > tiles such that it allows the upgrades to fit with minimal rotations.
> >
> > What is the idea behind this? Take the example how Keith Thomasson
> > built his tile sheets for postal play.
> >
> > Check the tile sheet of:
> > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm
> > It seems that in many cases those tiles are already orientated to
> > allow for easy upgrades:
> >
> > Define Facing 1 as the base rotation of an tile. Then it is the case
> > for example for an upgrade from tile 8 to tiles 19, 24, 29 the
> > possible upgrade will keep facings identical (thus no rotation of the
> > upgraded tiles is required). To upgrade to tile 16 and 25 one of the
> > possible upgrades has identical facings.
> >
> > So I came up with the idea if there is a solution that allows to
> > define an algorithm that defines a base rotations for all tiles such
> > that upgrades can be done with only a few rotations.
> >
> > At that time my idea was the following:
> > Id each hex side (for the example start with NW = 0, NE = 1, ... , W =
> > 5)
> >
> > A) Then sum up the id of all sides with at least one track leading to
> > it. Call that X. Compare each possible facing and choose that with
> > minimal X as the base rotation.
> >
> > It is easy to check that tiles 7, 8 and 9 are optimal rotated given in
> > that definition (and starting id=0 from NW).
> >
> > It is also the case for 16, 18, 19. However not for 20 (facing 2 has
> > minimal ids), and 23 (here facing 4), but again for 24.
> >
> > For tile 25 facing 1 and 3 have the same X. So a secondary criteria
> > would be helpful. Thus
> >
> > B) Sum up the ids of all tracks => Y
> > So given same X, then choose minimal Y as the base rotation.
> >
> > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and from id=0
> > to id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2 and from
> > id=2 to id=4 thus Y=8.
> >
> > C) What about tiles with stations on it? If you have only one station
> > which is connected to all tracks you can easily rely on ranking by X:
> > 57, 15, 53 have optimal facings, for 14 facing 2 is minimal.
> >
> > If you have two stations the minimal rotation is always found by
> > ranking with X and Y as long as the stations have identical attributes
> > and number of tracks.
> >
> > However in other cases it can get more difficult and one still has to
> > fall back to some base rotation defined in the master database.
> > (One Example is tile 11 in
> >
> http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.ht
> m
> > ). Facing 1, 3 and 5 have same X and Y.
> >
> > Related to this is he issue of symmetry: For example tile 9 has a
> > potential facing 4 (which is the rotation by 180 degree, but as tile 9
> > has exactly a symmetry there, this facing can ignored). So identity in
> > X and Y is a necessary condition for symmetry. For the 1830 tile set
> > it is also a sufficient condition (as far as I have checked, correct
> > me if I am wrong)
> >
> > In general the identity of X and Y is not a sufficient condition for
> > all
> > (existing) 18xx tiles (see example above) and if someone proposes an
> > algorithm that covers more cases than mine I would be very grateful.
> >
> > But for my case (an efficient algorithm) a necessary condition that is
> > easy to calculate is already very helpful as the more complex check is
> > only needed for those cases not eliminated by the simple one (similar
> > to a hash code to test equality).
> >
> >
> > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote:
> >> The currently ongoing discussion in the [18xx] group on how to
> >> describe tile lays is also of interest for Rails.  I'm in particular
> >> referring to cases where the Rails (TileDesigner) tile orientation
> >> (i.e., the tile number placement)  is different from the physical
> >> game. I just checked
> >> 1830 and 1856. The 1830 tile orientations are the same as in Rails
> >> (except tile #65), whereas with 1856 there are many differences.
> >>
> >> Take tile #23 as an example. The 1856 orientation of this tile is
> >> upside-down as compared with 1830 and Rails.  Now assume tile #9 has
> >> been laid before on hex O10 (connecting SW-NE) and is upgraded to
> >> tile #23 (adding a connection NW-NE).  Now the question is: how to
> >> display this upgrade in the map window and the game report?
> >>
> >> The Rails tile has the number as in 1830, on the SW side in this
> >> case, so the upgrade is now coded as #23/O10/SW.  However, the
> >> physical tile would have its number on the NE side, so in an FTF game
> >> the upgrade would be denoted as #23/O10/NE.
> >>
> >> My question is: what do we prefer?
> >>
> >> I am thinking on adding an optional attribute to <Tile> in
> >> TileSet.xml that specifies the 'base rotation' of the physical tile
> >> as compared with the Rails tile (or vice versa). This 'base rotation'
> >> would then be added (or
> >> subtracted) to the internal value to calculate the displayed tile
> >> orientation.
> >>
> >> So, to make the laid tile in this example be described as #23/O10/NE
> >> we should add an attribute like 'baseRotation="3"'.
> >>
> >> Any need for this feature? Should it  be an option?
> >>
> >> Erik.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- AppSumo Presents a FREE Video for the SourceForge Community by
> >> Eric Ries, the creator of the Lean Startup Methodology on "Lean
> >> Startup Secrets Revealed." This video shows you how to validate your
> >> ideas, optimize your ideas and identify your business strategy.
> >> http://p.sf.net/sfu/appsumosfdev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- AppSumo Presents a FREE Video for the SourceForge Community
> > by Eric Ries, the creator of the Lean Startup Methodology on "Lean
> > Startup Secrets Revealed." This video shows you how to validate your
> > ideas, optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets
> Revealed." This video shows you how to validate your ideas, optimize your
> ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel