rails-devel — List for discussion of Rails development

Re: [Rails-devel] TileOrientation Enumeration

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

Looks great.  Applied.

---Brett.



2011/6/12 Adam Badura <ab...@o2...>:
> In the attachment there is a minor refactoring for tile orientation which I
> developed while working on SVG advancement.
>
> I decided that it is useful on its own and is small enough for quick review.
> So here you have it.
>
> Adam Badura
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Train management

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

Note that, in 18EA there are triple train types - trains can be either
freight or express or local.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Jun 13, 2011 at 8:59 AM, Erik Vos <eri...@xs...> wrote:

> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
>
> > If you have flipTrain subclassing Train or have both be implementations
> of
> > the interface trainI is up to you. However I prefer the latter and trainI
> is an
> > unnecessary, as imho there is no need for an interface with only one
> > implementation (unless you provide an official API).
>
> We have many redundant interfaces, and I'd rather get rid of all of them,
> but there seems to be (or have been) a school of thought with some
> influence
> in this project that maintains that such interfaces are required about
> everywhere, just in case.  I prefer to use interfaces only when there is a
> actual need to provide some common functionality to classes in completely
> different hierarchies (good examples we have are the CashHolder, Moveable
> and MoveableHolder interfaces).
>
> We'll find out whether or not we really need TrainI when developing the
> dual
> train class; I will consider both options. This could the only other train
> class we will ever need: even the 18EU Pullmann has (right or wrong) been
> implemented with the standard Train class; its peculiarities are handled by
> special code.
>
> Erik.
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Train management

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
 
> If you have flipTrain subclassing Train or have both be implementations of
> the interface trainI is up to you. However I prefer the latter and trainI
is an
> unnecessary, as imho there is no need for an interface with only one
> implementation (unless you provide an official API).

We have many redundant interfaces, and I'd rather get rid of all of them,
but there seems to be (or have been) a school of thought with some influence
in this project that maintains that such interfaces are required about
everywhere, just in case.  I prefer to use interfaces only when there is a
actual need to provide some common functionality to classes in completely
different hierarchies (good examples we have are the CashHolder, Moveable
and MoveableHolder interfaces). 

We'll find out whether or not we really need TrainI when developing the dual
train class; I will consider both options. This could the only other train
class we will ever need: even the 18EU Pullmann has (right or wrong) been
implemented with the standard Train class; its peculiarities are handled by
special code.

Erik.

Re: [Rails-devel] Train management

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

Erik:
you are right: we already have a dual structure with train and trainType, 
where train represents certificate and trainType the actual train attributes.

I agree with your proposal and would even suggest to remove the following 
attributes from the train class:

    protected int majorStops;
    protected int minorStops;
    protected int cost;
    protected int cityScoreFactor;
    protected int townScoreFactor;
    protected int townCountIndicator;
    
Instead any request to train for this should be forwarded from train to the 
traintype.

Then the train class would represent the standard train certificate which only 
references one traintype and a flipTrain that can have several potential 
trainTypes plus a current one (which could be null as long as it is not 
defined).

If you have flipTrain subclassing Train or have both be implementations of the 
interface trainI is up to you. However I prefer the latter and trainI is an 
unnecessary, as imho there is no need for an interface with only one 
implementation (unless you provide an official API).

Stefan 


On Monday, June 13, 2011 01:58:18 pm Erik Vos wrote:
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > 
> > 
> > My proposal would be not to subclass the train class, but to implement
> > the trainI interface: The FlipTrain or MultiTrain class uses a state
> > pattern,
> 
> which
> 
> > keeps a list of possible normal Trains it can change to and mainly
> 
> forwards the
> 
> > calls to the current active one.
> 
> Sounds good, except that we then still must create and somewhere hold a
> current active train object.
> 
> Perhaps the following refinement would even further simplify matters:
> 
> Currently the Train objects hold their own copy of (most of) the fixed
> TrainType attributes, such as the number of stops.
> That's actually redundant, we could as well pass on the calls for those
> attributes to the corresponding TrainType.
> The TrainI types then only need the (dynamic) state objects.
> 
> For the new DualTrain class, this opens up the possibility to replace the
> 'current active train' by a 'current active train type', so we don't need
> to create any additional Train objects.  I think this still can be a Train
> subclass.
> 
> The main catch I then see is one of naming: we'll still need to distinguish
> a buyable certificate-style name (such as "2/1G"), to be used at initial
> buying time, and the actual train name, to be used everywhere else. That
> seems to be a much less drastic change to me than my original
> TrainCertificate proposal.
> 
> Erik
> 
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]


> My proposal would be not to subclass the train class, but to implement the
> trainI interface: The FlipTrain or MultiTrain class uses a state pattern,
which
> keeps a list of possible normal Trains it can change to and mainly
forwards the
> calls to the current active one.

Sounds good, except that we then still must create and somewhere hold a
current active train object. 

Perhaps the following refinement would even further simplify matters:

Currently the Train objects hold their own copy of (most of) the fixed
TrainType attributes, such as the number of stops.
That's actually redundant, we could as well pass on the calls for those
attributes to the corresponding TrainType. 
The TrainI types then only need the (dynamic) state objects.

For the new DualTrain class, this opens up the possibility to replace the
'current active train' by a 'current active train type', so we don't need to
create any additional Train objects.  I think this still can be a Train
subclass.

The main catch I then see is one of naming: we'll still need to distinguish
a buyable certificate-style name (such as "2/1G"), to be used at initial
buying time, and the actual train name, to be used everywhere else. That
seems to be a much less drastic change to me than my original
TrainCertificate proposal.

Erik

Re: [Rails-devel] Background Maps

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

Stefan,

Thanks for picking this up.  I knew it had to be done, but was indeed trusting upon you.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: zaterdag 11 juni 2011 8:08
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
> 
> The background map can now be activated in the configuration menu in the
> Map/Report section.
> The required changes are summarized below for future reference.
> I will move this example to the wiki with some more instructions on the
> configuration menu.
> Stefan
> 
> 
> To be supported in the configuration menu a new entry requires the
> following:
> A) An XML definition in data => Properties.xml
> 
> B) A default value in data.profiles => default.profile
> 
> C) A menu text in LocalisedText.properties Prefix is Config.label. followed by
> the property name
> 
> For this example here:
> A)
> <Property name="map.image.display" type="BOOLEAN" /> in section UI
> 
> B)
> map.image.display=no
> 
> C)
> Config.label.map.display=Display background map
> 
> 
> 
> 
> On Tuesday, June 07, 2011 06:04:37 pm Erik Vos wrote:
> > OK, I have committed the current code, which includes  an SVG
> > background map for 18EU (contributed by Bill Rosgen, IIRC).
> >
> > To enable seeing the map, one entry needs be added to your custom
> > my.properties file (I haven't tried to update the configuration menu yet):
> > - map.image.display=yes  (default no, in which case everything works
> > as before).
> >
> > I have included Bill Rosgen's patch to highlight selected hexes
> > somewhat differently.  Currently, it only affects display when the map is
> used.
> > The original highlighting looks ugly in this case.
> >
> > Please don't Zoom in serious play when the map image is used: it does
> > not yet work as it should. When I try, the tiles rescale correctly,
> > and so does the map image, but the latter soon gets out of sync.
> >
> > It's not clear to me how JSVGCanvas rescaling+resizing should be
> > programmed the right way. A scaling affine transform works fine, which
> > is what I used initially.  But it not change the canvas size, so part
> > of the map becomes invisible on zooming in. Only setting the canvas
> > bounds (setBounds()) initially does the whole job, and this is what
> > I'm currently using.  But on repeated zooming actions, it seems to
> > rescale the map image only every other time. Doing both (scale and
> setBounds) upscales the map twice.
> >
> > It may be a matter of timing, and perhaps some listener should be
> > invoked, but I cannot find any pointer on what exactly would be needed.
> >
> > Erik.
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: Erik Vos [mailto:eri...@xs...]
> > > Verzonden: dinsdag 7 juni 2011 13:57
> > > Aan: 'Development list for Rails: an 18xx game'
> > > Onderwerp: Re: [Rails-devel] Background Maps
> > >
> > > I fully agree that this is the way to go for the future.
> > > In the meantime, I will commit my and some of Bill's work on the map
> > > image integration (imperfect as it currently is), trusting that you
> > > will ultimately also be able to integrate SVG map images into your work.
> > >
> > > Erik
> > >
> > > > -----Oorspronkelijk bericht-----
> > > > Van: Adam Badura [mailto:ab...@o2...]
> > > > Verzonden: dinsdag 7 juni 2011 7:38
> > > > Aan: Development list for Rails: an 18xx game
> > > > Onderwerp: Re: [Rails-devel] Background Maps
> > > >
> > > > OK. Great. Then I shell continue this work. Yet I cannot promise
> > > > when it will be done. But I will try to report on progress every
> > > > now and then.
> > > >
> > > >     Adam Badura
> > > >
> > > > -----Oryginalna wiadomość-----
> > > > From: brett lentz
> > > > Sent: Tuesday, June 07, 2011 6:31 AM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Background Maps
> > > >
> > > > I think this is an excellent direction to continue working on.
> > > >
> > > > The patch looks like it consolidates a bunch of code into a couple
> > > > of classes, which looks good on first glance.
> > > >
> > > > I'd definitely like to see the finished patch once you're ready
> > > > for it to be merged into the codebase.
> > > >
> > > > ---Brett.
> > > >
> > > > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > > > > Sorry for the delay but I decided to adapt the patch to current
> > > > > code revision and have a look whether it does what I recall it
> > > > > did. Also I removed some additional works on symbols which I was
> > > > > doing along (this was the reason to start this work) but would
> > > > > be only distracting now.
> > > > >
> > > > > The code is mostly not documented as it is a working patch. Its
> > > > > not also "clean". But it does show that SVG Document isn't that hard.
> > > > > (To scroll or zoom use standard Batik components ways:
> > > > > Shift/Ctrl + moves with mouse buttons pressed.)
> > > > >
> > > > > So what do you think? Should I continue my work in this area?
> > > > >
> > > > > Adam Badura
> > > > >
> > > > > -----Oryginalna wiadomość----- From: Erik Vos
> > > > > Sent: Monday, June 06, 2011 2:43 PM
> > > > > To: 'Development list for Rails: an 18xx game'
> > > > > Subject: Re: [Rails-devel] Background Maps
> > > > >
> > > > > Adam,
> > > > >
> > > > > Congratulations with your second child!
> > > > >
> > > > > I'm certainly interested to have a look at your code, to check
> > > > > if I can merge it with my map display code.
> > > > >
> > > > > Some more comments below.
> > > > >
> > > > >> -----Oorspronkelijk bericht-----
> > > > >> Van: Adam Badura [mailto:ab...@o2...]
> > > > >>
> > > > >>    I was working on moving entire drawing to SVG (and this was
> > > > >> one
> > > > >>
> > > > >> of the reasons I tried to push Batik 1.7). But recently my
> > > > >> second child was born and there is some little chaos in my life
> > > > >> with not much time for such tasks.
> > > > >> I still have SVN Patch yet it is already conflicting at some
> > > > >> places with new code.
> > > > >>
> > > > >>    What I managed to get was to create an SVG document
> > > > >> containing
> > > > >>
> > > > >> map (all the tiles, either from map or track tiles). It looked
> > > > >> significantly better than our previous drawing mechanism. While
> > > > >> it was much less and much simpler code.
> > > > >> Also it scaled nicely.
> > > > >>
> > > > >>    What the code was missing was:
> > > > >> (1) drawing station tokens,
> > > > >> (2) drawing train paths,
> > > > >> (3) handling scaling and scrolling well,
> > > > >> (4) support tile selection.
> > > > >>
> > > > >>    First two would likely require some "hacking" as there is no
> > > > >>
> > > > >> easy way currently to do it in SVG Document as there is not
> > > > >> "specification" of tracks and stations on an SVG tile. But
> > > > >> previous code did it somehow and I guess that solution could be
> > > > >> used with SVG Document as well until (if ever) SVG tiles will
> > > > >> receive better description. (That is a topic interesting on its
> > > > >> own...)
> > > > >
> > > > > The tracks and the token spot locations are also (somewhat
> > > > > cryptically) defined in Tiles.xml, and these definitions are
> > > > > currently used to draw the train paths and tokens.
> > > > > For the time being (or perhaps forever) that can be left as is,
> > > > > drawing these objects in the top layer of the JLayeredPane that
> > > > > I'm currently using.
> > > > > However, that would still require achieving correct alignment of
> > > > > the two layers after zooming.
> > > > >
> > > > >>    I tries to handle third  by using JSVGSrolledPane (or
> > > > >> something
> > > > >>
> > > > >> called
> > > > >> similarly) but didn't achieve much. Then I had to interrupt my
> > > > >> investigations.
> > > > >
> > > > > I have also been thinking about JSVGScrolledPane, but I think
> > > > > using that will only become possible once we manage to do all
> > > > > drawing via
> > >
> > > JSVG.
> > >
> > > > >>    Fourth should be easy as Batik provides some events to
> > > > >> detect
> > > > >>
> > > > >> this. I expect this could be even easier then current mouse
> > > > >> handling. Borders around selected or marked tiles could likely
> > > > >> be achieved easily with CSS in the SVG Document.
> > > > >
> > > > > Sounds good.
> > > > >
> > > > > Erik.
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > -------- Simplify data backup and recovery for your virtual
> > > > > environment with vRanger.
> > > > > Installation's a snap, and flexible recovery options mean your
> > > > > data is safe, secure and there when you need it. Discover what
> > > > > all the cheering's about.
> > > > > Get your free trial download today.
> > > > > http://p.sf.net/sfu/quest-dev2dev2
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > -------- EditLive Enterprise is the world's most technically
> > > > > advanced content authoring tool. Experience the power of Track
> > > > > Changes, Inline Image Editing and ensure content is compliant
> > > > > with Accessibility Checking.
> > > > > http://p.sf.net/sfu/ephox-dev2dev
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -------- EditLive Enterprise is the world's most technically
> > > > advanced content authoring tool. Experience the power of Track
> > > > Changes, Inline Image Editing and ensure content is compliant with
> > > > Accessibility Checking.
> > > > http://p.sf.net/sfu/ephox-dev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -------- EditLive Enterprise is the world's most technically
> > > > advanced content authoring tool. Experience the power of Track
> > > > Changes, Inline Image Editing and ensure content is compliant with
> > > > Accessibility Checking.
> > > > http://p.sf.net/sfu/ephox-dev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > > --------------------------------------------------------------------
> > > -----
> > > ----- EditLive Enterprise is the world's most technically advanced
> > > content authoring tool. Experience the power of Track Changes,
> > > Inline Image Editing and ensure content is compliant with
> > > Accessibility Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Background Maps

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

The background map can now be activated in the configuration menu in the 
Map/Report section.
The required changes are summarized below for future reference.
I will move this example to the wiki with some more instructions on the 
configuration menu.
Stefan


To be supported in the configuration menu a new entry requires the following:
A) An XML definition in data => Properties.xml 

B) A default value in data.profiles => default.profile

C) A menu text in LocalisedText.properties
Prefix is Config.label. followed by the property name

For this example here:
A)
<Property name="map.image.display" type="BOOLEAN" />
in section UI

B)
map.image.display=no

C)
Config.label.map.display=Display background map




On Tuesday, June 07, 2011 06:04:37 pm Erik Vos wrote:
> OK, I have committed the current code, which includes  an SVG background
> map for 18EU (contributed by Bill Rosgen, IIRC).
> 
> To enable seeing the map, one entry needs be added to your custom
> my.properties file (I haven't tried to update the configuration menu yet):
> - map.image.display=yes  (default no, in which case everything works as
> before).
> 
> I have included Bill Rosgen's patch to highlight selected hexes somewhat
> differently.  Currently, it only affects display when the map is used. 
> The original highlighting looks ugly in this case.
> 
> Please don't Zoom in serious play when the map image is used: it does not
> yet work as it should. When I try, the tiles rescale correctly, and so
> does the map image, but the latter soon gets out of sync.
> 
> It's not clear to me how JSVGCanvas rescaling+resizing should be programmed
> the right way. A scaling affine transform works fine, which is what I used
> initially.  But it not change the canvas size, so part of the map becomes
> invisible on zooming in. Only setting the canvas bounds (setBounds())
> initially does the whole job, and this is what I'm currently using.  But
> on repeated zooming actions, it seems to rescale the map image only every
> other time. Doing both (scale and setBounds) upscales the map twice.
> 
> It may be a matter of timing, and perhaps some listener should be invoked,
> but I cannot find any pointer on what exactly would be needed.
> 
> Erik.
> 
> > -----Oorspronkelijk bericht-----
> > Van: Erik Vos [mailto:eri...@xs...]
> > Verzonden: dinsdag 7 juni 2011 13:57
> > Aan: 'Development list for Rails: an 18xx game'
> > Onderwerp: Re: [Rails-devel] Background Maps
> > 
> > I fully agree that this is the way to go for the future.
> > In the meantime, I will commit my and some of Bill's work on the map
> > image integration (imperfect as it currently is), trusting that you will
> > ultimately also be able to integrate SVG map images into your work.
> > 
> > Erik
> > 
> > > -----Oorspronkelijk bericht-----
> > > Van: Adam Badura [mailto:ab...@o2...]
> > > Verzonden: dinsdag 7 juni 2011 7:38
> > > Aan: Development list for Rails: an 18xx game
> > > Onderwerp: Re: [Rails-devel] Background Maps
> > > 
> > > OK. Great. Then I shell continue this work. Yet I cannot promise when
> > > it will be done. But I will try to report on progress every now and
> > > then.
> > > 
> > >     Adam Badura
> > > 
> > > -----Oryginalna wiadomość-----
> > > From: brett lentz
> > > Sent: Tuesday, June 07, 2011 6:31 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Background Maps
> > > 
> > > I think this is an excellent direction to continue working on.
> > > 
> > > The patch looks like it consolidates a bunch of code into a couple of
> > > classes, which looks good on first glance.
> > > 
> > > I'd definitely like to see the finished patch once you're ready for it
> > > to be merged into the codebase.
> > > 
> > > ---Brett.
> > > 
> > > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > > > Sorry for the delay but I decided to adapt the patch to current code
> > > > revision and have a look whether it does what I recall it did. Also
> > > > I removed some additional works on symbols which I was doing along
> > > > (this was the reason to start this work) but would be only
> > > > distracting now.
> > > > 
> > > > The code is mostly not documented as it is a working patch. Its not
> > > > also "clean". But it does show that SVG Document isn't that hard.
> > > > (To scroll or zoom use standard Batik components ways: Shift/Ctrl +
> > > > moves with mouse buttons pressed.)
> > > > 
> > > > So what do you think? Should I continue my work in this area?
> > > > 
> > > > Adam Badura
> > > > 
> > > > -----Oryginalna wiadomość----- From: Erik Vos
> > > > Sent: Monday, June 06, 2011 2:43 PM
> > > > To: 'Development list for Rails: an 18xx game'
> > > > Subject: Re: [Rails-devel] Background Maps
> > > > 
> > > > Adam,
> > > > 
> > > > Congratulations with your second child!
> > > > 
> > > > I'm certainly interested to have a look at your code, to check if I
> > > > can merge it with my map display code.
> > > > 
> > > > Some more comments below.
> > > > 
> > > >> -----Oorspronkelijk bericht-----
> > > >> Van: Adam Badura [mailto:ab...@o2...]
> > > >> 
> > > >>    I was working on moving entire drawing to SVG (and this was one
> > > >> 
> > > >> of the reasons I tried to push Batik 1.7). But recently my second
> > > >> child was born and there is some little chaos in my life with not
> > > >> much time for such tasks.
> > > >> I still have SVN Patch yet it is already conflicting at some places
> > > >> with new code.
> > > >> 
> > > >>    What I managed to get was to create an SVG document containing
> > > >> 
> > > >> map (all the tiles, either from map or track tiles). It looked
> > > >> significantly better than our previous drawing mechanism. While it
> > > >> was much less and much simpler code.
> > > >> Also it scaled nicely.
> > > >> 
> > > >>    What the code was missing was:
> > > >> (1) drawing station tokens,
> > > >> (2) drawing train paths,
> > > >> (3) handling scaling and scrolling well,
> > > >> (4) support tile selection.
> > > >> 
> > > >>    First two would likely require some "hacking" as there is no
> > > >> 
> > > >> easy way currently to do it in SVG Document as there is not
> > > >> "specification" of tracks and stations on an SVG tile. But previous
> > > >> code did it somehow and I guess that solution could be used with
> > > >> SVG Document as well until (if ever) SVG tiles will receive better
> > > >> description. (That is a topic interesting on its
> > > >> own...)
> > > > 
> > > > The tracks and the token spot locations are also (somewhat
> > > > cryptically) defined in Tiles.xml, and these definitions are
> > > > currently used to draw the train paths and tokens.
> > > > For the time being (or perhaps forever) that can be left as is,
> > > > drawing these objects in the top layer of the JLayeredPane that I'm
> > > > currently using.
> > > > However, that would still require achieving correct alignment of the
> > > > two layers after zooming.
> > > > 
> > > >>    I tries to handle third  by using JSVGSrolledPane (or something
> > > >> 
> > > >> called
> > > >> similarly) but didn't achieve much. Then I had to interrupt my
> > > >> investigations.
> > > > 
> > > > I have also been thinking about JSVGScrolledPane, but I think using
> > > > that will only become possible once we manage to do all drawing via
> > 
> > JSVG.
> > 
> > > >>    Fourth should be easy as Batik provides some events to detect
> > > >> 
> > > >> this. I expect this could be even easier then current mouse
> > > >> handling. Borders around selected or marked tiles could likely be
> > > >> achieved easily with CSS in the SVG Document.
> > > > 
> > > > Sounds good.
> > > > 
> > > > Erik.
> > > > 
> > > > 
> > > > --------------------------------------------------------------------
> > > > --
> > > > -------- Simplify data backup and recovery for your virtual
> > > > environment with vRanger.
> > > > Installation's a snap, and flexible recovery options mean your data
> > > > is safe, secure and there when you need it. Discover what all the
> > > > cheering's about.
> > > > Get your free trial download today.
> > > > http://p.sf.net/sfu/quest-dev2dev2
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > > --------------------------------------------------------------------
> > > > --
> > > > -------- EditLive Enterprise is the world's most technically
> > > > advanced content authoring tool. Experience the power of Track
> > > > Changes, Inline Image Editing and ensure content is compliant with
> > > > Accessibility Checking.
> > > > http://p.sf.net/sfu/ephox-dev2dev
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -------- EditLive Enterprise is the world's most technically advanced
> > > content authoring tool. Experience the power of Track Changes, Inline
> > > Image Editing and ensure content is compliant with Accessibility
> > > Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > -------- EditLive Enterprise is the world's most technically advanced
> > > content authoring tool. Experience the power of Track Changes, Inline
> > > Image Editing and ensure content is compliant with Accessibility
> > > Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

On the train certificate vs. new train type:

I guess that the biggest disadvantage of the train certificate solution is the 
problem to keep certificates and trains combined correctly. 
On reload and especially undo/redo situations the certificates and trains have 
to be the identical objects for each transfer. Otherwise it can get a mess 
similar to situations that haunted/haunt transfer of share certificates. 

A robust solution would be to id both certificate and train, but this requires 
changing all actions that refer to the trains.

My proposal would be not to subclass the train class, but to implement the 
trainI interface: The FlipTrain or MultiTrain class uses a state pattern, 
which keeps a list of possible normal Trains it can change to and mainly 
forwards the calls to the current active one. 

In addition it has some additional methods/attributes which define the 
behavior of the flip/state change.

From my point of view this would keep the number of changes to the overall 
code minimal and does not require to keep certificates and trains objects 
aligned all the time.

But as always there are pros and cons to every solution.

Stefan


On Friday, June 10, 2011 06:55:58 pm brett lentz wrote:
> On Fri, Jun 10, 2011 at 3:02 AM, Erik Vos <eri...@xs...> wrote:
> >> -----Oorspronkelijk bericht-----
> >> Van: Phil Davies [mailto:de...@gm...]
> >> 
> >> On 9 June 2011 22:34, John David Galt <jd...@di...>
> >> 
> >> wrote:
> >> >   But there is no reason ever to create a "train certificate" object,
> >> > because the type of a train becomes fixed in stone as soon as it is
> >> > first acquired by a company.  I don't know of an exception to this in
> > 
> > any
> > 
> >> game.
> >> 
> >> Erik already mentioned above but in 18VA, if a train gets discarded to
> >> the pool it reverts to being a certificate and the new purchaser can
> >> choose
> > 
> > which
> > 
> >> type of train it is.
> > 
> > Indeed. In any case we need some kind of object that joins the two train
> > types.
> > 
> > Another approach that I'm considering is a new train subclass named
> > DualTrain. This type would behave as a train if owned by a company, and
> > as a dual train certificate if owned by the Bank.
> > The upside is, that I suspect less changes are needed to the train
> > handling code, but the downsides are (1) a higher chance to overlook
> > certain required changes, and (2) we still don't have a solution for
> > 18GA, for which we really need a different (or additional) way to create
> > trains.
> > Still this approach might turn out to be the easiest one.  The jury is
> > out.
> > 
> > Erik.
> 
> I support your initial proposal. It makes sense to have a base
> class/interface used for creating as many sub-classes as are needed to
> describe all of the various variations on "Train".
> 
> We already do this with just about every other concept. Hex,
> Certificate, StockMarket, etc. etc. etc.
> 
> I'd much rather have a clear class hierarchy. The primary benefit will
> be readable, understandable code rather than a set of sub-classes that
> makes everyone ask, "Why is it done this way?"
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

On Fri, Jun 10, 2011 at 3:02 AM, Erik Vos <eri...@xs...> wrote:
>> -----Oorspronkelijk bericht-----
>> Van: Phil Davies [mailto:de...@gm...]
>>
>> On 9 June 2011 22:34, John David Galt <jd...@di...>
>> wrote:
>> >   But there is no reason ever to create a "train certificate" object,
>> > because the type of a train becomes fixed in stone as soon as it is
>> > first acquired by a company.  I don't know of an exception to this in
> any
>> game.
>>
>> Erik already mentioned above but in 18VA, if a train gets discarded to the
>> pool it reverts to being a certificate and the new purchaser can choose
> which
>> type of train it is.
>
> Indeed. In any case we need some kind of object that joins the two train
> types.
>
> Another approach that I'm considering is a new train subclass named
> DualTrain. This type would behave as a train if owned by a company, and as a
> dual train certificate if owned by the Bank.
> The upside is, that I suspect less changes are needed to the train handling
> code, but the downsides are (1) a higher chance to overlook certain required
> changes, and (2) we still don't have a solution for 18GA, for which we
> really need a different (or additional) way to create trains.
> Still this approach might turn out to be the easiest one.  The jury is out.
>
> Erik.
>

I support your initial proposal. It makes sense to have a base
class/interface used for creating as many sub-classes as are needed to
describe all of the various variations on "Train".

We already do this with just about every other concept. Hex,
Certificate, StockMarket, etc. etc. etc.

I'd much rather have a clear class hierarchy. The primary benefit will
be readable, understandable code rather than a set of sub-classes that
makes everyone ask, "Why is it done this way?"

---Brett.

Re: [Rails-devel] Rails 1.4 1835 playtest - hangs early

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

Found this old message waiting to be addressed (finally):

> -----Oorspronkelijk bericht-----
> Van: John David Galt [mailto:jd...@di...]
> 
> I tried it with 1835.  Contrary to what I wrote in the 18EU review, the
> 1835 map doesn't show the Y or XX hexes.  It does very nicely show the
> impassable hex side NW of Hamburg.

The 1835 map did always show the XX tiles, but for the Y hexes the standard
city map tiles #-10 were used so far.  These have now been replaced by the
18EU Y city map tiles #-3007. 
Additional benefit is that the upgrade rules could be simplified.

> I got as far as laying tiles with the BY in OR1 (thanks for changing the
company
> names!)  Then it hangs (no "Buy Train" button, "Done" is grayed out, and I
> don't even get the usual dialog saying BY has no train.)
> 
> Save file is attached.  If the list filters it, I'll mail it on request.

This problem was apparently fixed, or it miraculously went away, I don't
remember.  In any case, it works for me now.

Erik.

Re: [Rails-devel] Train management

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

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> 
> On 9 June 2011 22:34, John David Galt <jd...@di...>
> wrote:
> >   But there is no reason ever to create a "train certificate" object,
> > because the type of a train becomes fixed in stone as soon as it is
> > first acquired by a company.  I don't know of an exception to this in
any
> game.
> 
> Erik already mentioned above but in 18VA, if a train gets discarded to the
> pool it reverts to being a certificate and the new purchaser can choose
which
> type of train it is.

Indeed. In any case we need some kind of object that joins the two train
types.

Another approach that I'm considering is a new train subclass named
DualTrain. This type would behave as a train if owned by a company, and as a
dual train certificate if owned by the Bank.
The upside is, that I suspect less changes are needed to the train handling
code, but the downsides are (1) a higher chance to overlook certain required
changes, and (2) we still don't have a solution for 18GA, for which we
really need a different (or additional) way to create trains. 
Still this approach might turn out to be the easiest one.  The jury is out.

Erik.

Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get free tile lays

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

Done.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: woensdag 8 juni 2011 23:14
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get
free
> tile lays
> 
> I agree.
> 
> On Wednesday, June 08, 2011 10:17:30 pm Erik Vos wrote:
> > Indeed I'm not familiar with 1889, so this case has escaped my
attention.
> >
> > I think the simplest solution would be to move the check into
> > checkNormalTileLay().
> > See attachment.  Works for me.  If you agree, I'll commit this way of
> > fixing the bug.
> >
> > Erik.
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: Stefan Frey [mailto:ste...@we...]
> > > Verzonden: woensdag 8 juni 2011 21:05
> > > Aan: Development list for Rails: an 18xx game
> > > Onderwerp: Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't
> > > get
> >
> > free
> >
> > > tile lays
> > >
> > > On the specific issue:
> > > I am responding as I am the one to blame for 1889:
> > > Indeed the method getSpecialTileLays in OperatingRound is the
> > > critical
> >
> > one.
> >
> > > This was a caused by a recent change by Erik, as he cleaned up the
> > > Special
> >
> > Tile
> >
> > > Lay code at several places in the codebase. As he was (most likely)
> > > not
> >
> > aware
> >
> > > of the D property of being able to lay any tile, he assumed that a
> > > tile id
> >
> > would
> >
> > > always be specified.
> > >
> > > I would add a check to your fix to capture this case and otherwise
> > > keep
> >
> > with
> >
> > > the old flow, unless Erik has a better idea/other opinion?
> > >
> > > In general:
> > > There are two things we could improve to avoid such issues:
> > > A) Better documentation of the XML methods (for example which
> > > attributes are mandatory or optional and would an omission implies).
> > >
> > > B) This problem would have been captured in principle by my
> > > automated testing of existing game files. However it seems (to me)
> > > that those tests
> >
> > got
> >
> > > a little sidetracked, since the time I got sidetracked by real world
> >
> > issues ;-) I
> >
> > > will update the test settings and include more docs on them in the
> > > wiki
> >
> > (by
> >
> > > collecting my information sent out to the mailing list).
> > >
> > > Stefan
> > >
> > > On Monday, June 06, 2011 10:28:29 am Bill Rosgen wrote:
> > > > In a game I am playing, we encountered a bug in 1.4.2 that is not
> > > > in
> >
> > 1.4.1.
> >
> > > >  Specifically, there is a company with the D private, which allows
> > > >
> > > > free tiles to be laid in the mountains (in rails XML, these tile
> > > > lays are free="yes" and extra="no").  The attached .rails file
> > > > exhibits the
> > > > problem: Brad's TR does not get offered a free tile lay in F5.
> > > >
> > > > Tracking the problem down lead to the method getSpecialTileLays in
> > > > OperatingRound: when testing to see if special tile lays with
> > > > extra="no" are possible, this method checks to see if the tile
> > > > specified in the SpecialTileLay can be laid.  Unfortunately in the
> > > > 1889 Private D is not restricted to a specific tile, so the action
> > > > wasn't being added to the list.  The attached patch changes this
> > > > to a different (and I think equivalent?) method of testing if
> > > > normal tile lays are still available -- I check that the map
> > > > tileLaysPerColour is not empty (as is done by the method
> > > > areTileLaysPossible when it tests if normal tile lays are
available).
> > > >
> > > > It is not clear to me that this is the best solution.  Other
> > > > solutions might be:
> > > >
> > > > 1) Add three SpecialTileLays to Private D in 1889, one for each
> > > > available tile (7,8,9, in this case) 2) Change SpecialTileLay to
> > > > keep a list of available tiles, with corresponding changes to
> > > > OperatingRound and LayTile
> > > > 3) If the tile in SpecialTileLay is null, treat this as no
restriction:
> > > > get the lists of all available tiles in the restricted hexes and
> > > > check to see if any of them are valid, adding LayTile actions as
> appropriate.
> > > >
> > > > Bill Rosgen
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > EditLive Enterprise is the world's most technically advanced content
> > > authoring tool. Experience the power of Track Changes, Inline Image
> >
> > Editing
> >
> > > and ensure content is compliant with Accessibility Checking.
> > > http://p.sf.net/sfu/ephox-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

OK, the 18TN 4-train obsoleting on buying the 2nd 6-train should work now.

 

The implementation is a bit provisional, as it only covers rusting yet.  I
think we'll have to move to a more generic approach, in which any type of
action can be triggered that is normally associated with phase changes. 

 

Erik.

 

Van: Erik Vos [mailto:eri...@xs...] 
Verzonden: donderdag 9 juni 2011 20:56
Aan: 'Development list for Rails: an 18xx game'
Onderwerp: Re: [Rails-devel] Train management

 

Ah yes, thanks for the reminder.  I believe this can be accomplished
independently from the other issues.

Erik.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: donderdag 9 juni 2011 18:00
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

Would this be a good time to implement the phase change effects of the nth
train being purchased as in the Derrick games?

18TN: 4-trains obsolete (not rust) when the second 6-train is purchased
(4-trains the the pool are removed).

Re: [Rails-devel] Train management

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

On 9 June 2011 22:34, John David Galt <jd...@di...> wrote:
>   But there is no reason ever to create a "train certificate" object,
> because the type of a train becomes fixed in stone as soon as it is first
> acquired by a company.  I don't know of an exception to this in any game.

Erik already mentioned above but in 18VA, if a train gets discarded to
the pool it reverts to being a certificate and the new purchaser can
choose which type of train it is.

Phil

Re: [Rails-devel] Train management

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

On 2011-06-09 07:10, Erik Vos wrote:
> As announced before, I have been thinking about how to upgrade train
> management to enable some new features that currently can't be implemented
> (notably items 2 and 5 of the below list).
> 
> I'm aware of the following cases to  be taken into account:
> 1. Normal trains.
> 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
> aware of having such flip-side trains, and which have considered so far).
> 3. Initial trains (as in 18EU).
> 4. Fixed trains (at a cost, as some 1825 minors have).
> 5. Extra trains from a private special property (as in 18GA).
> Any others?
> 
> The basic idea is to separate train certificates from actual trains.  

I don't see any reason to want to do this.  I would handle all these cases
as follows.

Case 1: The train is an object as now.

Case 2: There can be more than one type of new train available at a time.
Create XML attributes for each type of train that allow that type to become
available for purchase as a result of an event, and that allow the total
number of available trains of two types to be limited to a constant.
   In addition to the cases you've listed, one or both of these would apply
to: diesels in 1830 and 1856 (available after first 6 train); 'G' trains in
1837; meter gauge trains in 1853 (especially the 2/1G trains in the Stuart
Dagger variant, though I'm not sure if those made it into 1853v2); and the
two versions of types I-V in 2038.
   But there is no reason ever to create a "train certificate" object,
because the type of a train becomes fixed in stone as soon as it is first
acquired by a company.  I don't know of an exception to this in any game.

Cases 3, 4, 5: Simply allow a company to be hard-coded as having specified
train(s) before the game starts.  This includes privates (for case 5).  By
default a private company which owns a train can't do anything with it, not
even sell it, so no new code should be needed; but of course 2038's probe
would be an exception.

Re: [Rails-devel] Train management

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

Hi,
some train specials from OO-Games
1844, Switzerland, private company Nr. 7 owns a train (5h) which can 
assigned to a company with a trainslot and run it in its first operating 
round
1844, Regional-company can acquire only h-Trains.
1844, when the first 3-train is bought, all 2 Trains became 2h-Trains (3 
to 3h with 5 train, 4 to 4h with 6-Train, 5 to 5h with 8-Train)
1853, lookout version, if opening of small companies (nr.(5),6,7,8) 
occurs, all 6 2 Trains became 7 2/1M Trains, a 2M and a 3M Train are added.
     if all 7 2/1M trains are bought before the first 3-Train, more 2/1M 
trains are available until the first 3-Train
     big company (1-4 (5)) can't buy 1M-Trains.
18C2C, Merged company have 2 Lok-Shells,
1824/1837 Austria, coal company can only own G-Trains
1880 2R (restaurated 2 Trains, which take a trainslot but are not 
sufficient for the lok duty
1880, China, private has the right, to take an actual train before the 
company run, or when it is closed with the first 4-Train, take the 
second 4-train.
     at this moment appointment to a company with no free trainslot is 
possible, just throw away an older one. if no appointment is
     possible, the 4-train is gone

greetings
Volker Schnell

Am 09.06.2011 21:14, schrieb Erik Vos:
>
> If I’m not mistaken, the SBB fixed train behaves not any differently 
> than the 1825 minor fixed trains, except that it is for free.
>
> Erik.
>
> *Van:*John A. Tamplin [mailto:ja...@ja...]
> *Verzonden:* donderdag 9 juni 2011 18:12
> *Aan:* Development list for Rails: an 18xx game
> *Onderwerp:* Re: [Rails-devel] Train management
>
> On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs... 
> <mailto:eri...@xs...>> wrote:
>
> As announced before, I have been thinking about how to upgrade train
> management to enable some new features that currently can't be implemented
> (notably items 2 and 5 of the below list).
>
> I'm aware of the following cases to  be taken into account:
> 1. Normal trains.
> 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
> aware of having such flip-side trains, and which have considered so far).
> 3. Initial trains (as in 18EU).
> 4. Fixed trains (at a cost, as some 1825 minors have).
> 5. Extra trains from a private special property (as in 18GA).
> Any others?
>
> In 1844, the state railroad has a pre-printed 5H on its charter that 
> never goes away but counts towards the train limit.
>
>
> -- 
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

If I’m not mistaken, the SBB fixed train behaves not any differently than the 1825 minor fixed trains, except that it is for free.

Erik.

 

Van: John A. Tamplin [mailto:ja...@ja...] 
Verzonden: donderdag 9 juni 2011 18:12
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs...> wrote:

As announced before, I have been thinking about how to upgrade train
management to enable some new features that currently can't be implemented
(notably items 2 and 5 of the below list).

I'm aware of the following cases to  be taken into account:
1. Normal trains.
2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
aware of having such flip-side trains, and which have considered so far).
3. Initial trains (as in 18EU).
4. Fixed trains (at a cost, as some 1825 minors have).
5. Extra trains from a private special property (as in 18GA).
Any others?

 

In 1844, the state railroad has a pre-printed 5H on its charter that never goes away but counts towards the train limit.


-- 
John A. Tamplin

Re: [Rails-devel] Train management

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

Good point, I'll keep it in mind.

> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> Verzonden: donderdag 9 juni 2011 16:47
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Train management
> 
> They aren't considered separately but going from memory the 6/4D trains in
> 18Ardennes also work this way.  With the further restriction that only 10
> share companies can buy the 4D (presumably limit the purchase of
traincerts
> by company should be fairly trivial)
> 
> Phil
> 
> On 9 June 2011 15:10, Erik Vos <eri...@xs...> wrote:
> > As announced before, I have been thinking about how to upgrade train
> > management to enable some new features that currently can't be
> > implemented (notably items 2 and 5 of the below list).
> >
> > I'm aware of the following cases to  be taken into account:
> > 1. Normal trains.
> > 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games
> > I'm aware of having such flip-side trains, and which have considered so
far).
> > 3. Initial trains (as in 18EU).
> > 4. Fixed trains (at a cost, as some 1825 minors have).
> > 5. Extra trains from a private special property (as in 18GA).
> > Any others?
> >
> > The basic idea is to separate train certificates from actual trains.
> >
> > Train certificates are objects that can be traded.  Each certificate
> > represents a potential train, designated by a train type object.  A
> > dual train certificate represents one of two potential trains, and is
> > therefore linked to two train type objects.
> >
> > Trains are objects owned and held by companies only.  Trains are no
> > longer created at the game start, but at the time that a company
> > acquires a train by whatever means.  The possibilities are:
> > 1. Buy a normal train certificate: create a train object.
> > 2. Buy a dual train certificate: ask the player what type is wanted
> > (this can affect the price), and instantiate a train of that train type
only.
> > 3. An initial train as in 18EU is obtained by autobuying a train
> > (certificate) at zero cost at floating time (similar to as it works
now).
> > 4. A fixed train as in 1825 is obtained by autobuying a non-tradable
> > train (perhaps without a certificate) at nonzero cost at floating time.
> > 5. The 18GA extra 2-train is not tradable and is not related to a
> > train certificate. It is created when a company buys the OSRR private
> > before phase 4.
> >
> > When a train is traded between companies, both the train certificate
> > and the train object are moved.
> > When a train is discarded to the Pool, the train certificate is moved,
> > but the train object is destroyed.
> > These two procedures are formulated this way to precisely implement
> > the very explicit 18VA dual train rules: when a dual train certificate
> > is traded between companies, the initial train choice must still be
> > honoured, but when a train certificate enters the pool, that choice is
> > erased.  As far as I can see, the 1846 rules are somewhat less
> > explicit but no different. The 18Scan rules seem to be silent on this
> > matter, but I assume the 18VA rules also apply to 18Scan. If anyone is
> aware of different cases, please let me know.
> >
> > Any comments?  Do other cases exist that I have overlooked but need be
> > considered separately?
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Train management

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

Ah yes, thanks for the reminder.  I believe this can be accomplished
independently from the other issues.

Erik.

 

Van: Scott Petersen [mailto:sc...@re...] 
Verzonden: donderdag 9 juni 2011 18:00
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Train management

 

Would this be a good time to implement the phase change effects of the nth
train being purchased as in the Derrick games?

18TN: 4-trains obsolete (not rust) when the second 6-train is purchased
(4-trains the the pool are removed).

Re: [Rails-devel] Train management

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

On Thu, Jun 9, 2011 at 10:10 AM, Erik Vos <eri...@xs...> wrote:

> As announced before, I have been thinking about how to upgrade train
> management to enable some new features that currently can't be implemented
> (notably items 2 and 5 of the below list).
>
> I'm aware of the following cases to  be taken into account:
> 1. Normal trains.
> 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
> aware of having such flip-side trains, and which have considered so far).
> 3. Initial trains (as in 18EU).
> 4. Fixed trains (at a cost, as some 1825 minors have).
> 5. Extra trains from a private special property (as in 18GA).
> Any others?
>

In 1844, the state railroad has a pre-printed 5H on its charter that never
goes away but counts towards the train limit.

-- 
John A. Tamplin

Re: [Rails-devel] Train management

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

Would this be a good time to implement the phase change effects of the nth
train being purchased as in the Derrick games?
18TN: 4-trains obsolete (not rust) when the second 6-train is purchased
(4-trains the the pool are removed).

Re: [Rails-devel] Train management

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

They aren't considered separately but going from memory the 6/4D
trains in 18Ardennes also work this way.  With the further restriction
that only 10 share companies can buy the 4D (presumably limit the
purchase of traincerts by company should be fairly trivial)

Phil

On 9 June 2011 15:10, Erik Vos <eri...@xs...> wrote:
> As announced before, I have been thinking about how to upgrade train
> management to enable some new features that currently can't be implemented
> (notably items 2 and 5 of the below list).
>
> I'm aware of the following cases to  be taken into account:
> 1. Normal trains.
> 2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
> aware of having such flip-side trains, and which have considered so far).
> 3. Initial trains (as in 18EU).
> 4. Fixed trains (at a cost, as some 1825 minors have).
> 5. Extra trains from a private special property (as in 18GA).
> Any others?
>
> The basic idea is to separate train certificates from actual trains.
>
> Train certificates are objects that can be traded.  Each certificate
> represents a potential train, designated by a train type object.  A dual
> train certificate represents one of two potential trains, and is therefore
> linked to two train type objects.
>
> Trains are objects owned and held by companies only.  Trains are no longer
> created at the game start, but at the time that a company acquires a train
> by whatever means.  The possibilities are:
> 1. Buy a normal train certificate: create a train object.
> 2. Buy a dual train certificate: ask the player what type is wanted (this
> can affect the price), and instantiate a train of that train type only.
> 3. An initial train as in 18EU is obtained by autobuying a train
> (certificate) at zero cost at floating time (similar to as it works now).
> 4. A fixed train as in 1825 is obtained by autobuying a non-tradable train
> (perhaps without a certificate) at nonzero cost at floating time.
> 5. The 18GA extra 2-train is not tradable and is not related to a train
> certificate. It is created when a company buys the OSRR private before phase
> 4.
>
> When a train is traded between companies, both the train certificate and the
> train object are moved.
> When a train is discarded to the Pool, the train certificate is moved, but
> the train object is destroyed.
> These two procedures are formulated this way to precisely implement the very
> explicit 18VA dual train rules: when a dual train certificate is traded
> between companies, the initial train choice must still be honoured, but when
> a train certificate enters the pool, that choice is erased.  As far as I can
> see, the 1846 rules are somewhat less explicit but no different. The 18Scan
> rules seem to be silent on this matter, but I assume the 18VA rules also
> apply to 18Scan. If anyone is aware of different cases, please let me know.
>
> Any comments?  Do other cases exist that I have overlooked but need be
> considered separately?
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Train management

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

As announced before, I have been thinking about how to upgrade train
management to enable some new features that currently can't be implemented
(notably items 2 and 5 of the below list).

I'm aware of the following cases to  be taken into account:
1. Normal trains.
2. Dual trains, as in 18VA, 18Scan and 1846 (these are the three games I'm
aware of having such flip-side trains, and which have considered so far).
3. Initial trains (as in 18EU).
4. Fixed trains (at a cost, as some 1825 minors have).
5. Extra trains from a private special property (as in 18GA).
Any others?

The basic idea is to separate train certificates from actual trains.  

Train certificates are objects that can be traded.  Each certificate
represents a potential train, designated by a train type object.  A dual
train certificate represents one of two potential trains, and is therefore
linked to two train type objects.

Trains are objects owned and held by companies only.  Trains are no longer
created at the game start, but at the time that a company acquires a train
by whatever means.  The possibilities are:
1. Buy a normal train certificate: create a train object.
2. Buy a dual train certificate: ask the player what type is wanted (this
can affect the price), and instantiate a train of that train type only.
3. An initial train as in 18EU is obtained by autobuying a train
(certificate) at zero cost at floating time (similar to as it works now).
4. A fixed train as in 1825 is obtained by autobuying a non-tradable train
(perhaps without a certificate) at nonzero cost at floating time.
5. The 18GA extra 2-train is not tradable and is not related to a train
certificate. It is created when a company buys the OSRR private before phase
4.

When a train is traded between companies, both the train certificate and the
train object are moved.
When a train is discarded to the Pool, the train certificate is moved, but
the train object is destroyed.  
These two procedures are formulated this way to precisely implement the very
explicit 18VA dual train rules: when a dual train certificate is traded
between companies, the initial train choice must still be honoured, but when
a train certificate enters the pool, that choice is erased.  As far as I can
see, the 1846 rules are somewhat less explicit but no different. The 18Scan
rules seem to be silent on this matter, but I assume the 18VA rules also
apply to 18Scan. If anyone is aware of different cases, please let me know. 

Any comments?  Do other cases exist that I have overlooked but need be
considered separately?  

Erik.

Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get free tile lays

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

I agree.

On Wednesday, June 08, 2011 10:17:30 pm Erik Vos wrote:
> Indeed I'm not familiar with 1889, so this case has escaped my attention.
> 
> I think the simplest solution would be to move the check into
> checkNormalTileLay().
> See attachment.  Works for me.  If you agree, I'll commit this way of
> fixing the bug.
> 
> Erik.
> 
> > -----Oorspronkelijk bericht-----
> > Van: Stefan Frey [mailto:ste...@we...]
> > Verzonden: woensdag 8 juni 2011 21:05
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get
> 
> free
> 
> > tile lays
> > 
> > On the specific issue:
> > I am responding as I am the one to blame for 1889:
> > Indeed the method getSpecialTileLays in OperatingRound is the critical
> 
> one.
> 
> > This was a caused by a recent change by Erik, as he cleaned up the
> > Special
> 
> Tile
> 
> > Lay code at several places in the codebase. As he was (most likely) not
> 
> aware
> 
> > of the D property of being able to lay any tile, he assumed that a tile
> > id
> 
> would
> 
> > always be specified.
> > 
> > I would add a check to your fix to capture this case and otherwise keep
> 
> with
> 
> > the old flow, unless Erik has a better idea/other opinion?
> > 
> > In general:
> > There are two things we could improve to avoid such issues:
> > A) Better documentation of the XML methods (for example which attributes
> > are mandatory or optional and would an omission implies).
> > 
> > B) This problem would have been captured in principle by my automated
> > testing of existing game files. However it seems (to me) that those tests
> 
> got
> 
> > a little sidetracked, since the time I got sidetracked by real world
> 
> issues ;-) I
> 
> > will update the test settings and include more docs on them in the wiki
> 
> (by
> 
> > collecting my information sent out to the mailing list).
> > 
> > Stefan
> > 
> > On Monday, June 06, 2011 10:28:29 am Bill Rosgen wrote:
> > > In a game I am playing, we encountered a bug in 1.4.2 that is not in
> 
> 1.4.1.
> 
> > >  Specifically, there is a company with the D private, which allows
> > > 
> > > free tiles to be laid in the mountains (in rails XML, these tile lays
> > > are free="yes" and extra="no").  The attached .rails file exhibits the
> > > problem: Brad's TR does not get offered a free tile lay in F5.
> > > 
> > > Tracking the problem down lead to the method getSpecialTileLays in
> > > OperatingRound: when testing to see if special tile lays with
> > > extra="no" are possible, this method checks to see if the tile
> > > specified in the SpecialTileLay can be laid.  Unfortunately in the
> > > 1889 Private D is not restricted to a specific tile, so the action
> > > wasn't being added to the list.  The attached patch changes this to a
> > > different (and I think equivalent?) method of testing if normal tile
> > > lays are still available -- I check that the map tileLaysPerColour is
> > > not empty (as is done by the method areTileLaysPossible when it tests
> > > if normal tile lays are available).
> > > 
> > > It is not clear to me that this is the best solution.  Other solutions
> > > might be:
> > > 
> > > 1) Add three SpecialTileLays to Private D in 1889, one for each
> > > available tile (7,8,9, in this case) 2) Change SpecialTileLay to keep
> > > a list of available tiles, with corresponding changes to
> > > OperatingRound and LayTile
> > > 3) If the tile in SpecialTileLay is null, treat this as no restriction:
> > > get the lists of all available tiles in the restricted hexes and check
> > > to see if any of them are valid, adding LayTile actions as appropriate.
> > > 
> > > Bill Rosgen
> 
> ---------------------------------------------------------------------------
> - --
> 
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> 
> Editing
> 
> > and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get free tile lays

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

Indeed I'm not familiar with 1889, so this case has escaped my attention.

I think the simplest solution would be to move the check into
checkNormalTileLay().
See attachment.  Works for me.  If you agree, I'll commit this way of fixing
the bug.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: woensdag 8 juni 2011 21:05
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1889 Bug (and patch): D Private doesn't get
free
> tile lays
> 
> On the specific issue:
> I am responding as I am the one to blame for 1889:
> Indeed the method getSpecialTileLays in OperatingRound is the critical
one.
> 
> This was a caused by a recent change by Erik, as he cleaned up the Special
Tile
> Lay code at several places in the codebase. As he was (most likely) not
aware
> of the D property of being able to lay any tile, he assumed that a tile id
would
> always be specified.
> 
> I would add a check to your fix to capture this case and otherwise keep
with
> the old flow, unless Erik has a better idea/other opinion?
> 
> In general:
> There are two things we could improve to avoid such issues:
> A) Better documentation of the XML methods (for example which attributes
> are mandatory or optional and would an omission implies).
> 
> B) This problem would have been captured in principle by my automated
> testing of existing game files. However it seems (to me) that those tests
got
> a little sidetracked, since the time I got sidetracked by real world
issues ;-) I
> will update the test settings and include more docs on them in the wiki
(by
> collecting my information sent out to the mailing list).
> 
> Stefan
> 
> 
> On Monday, June 06, 2011 10:28:29 am Bill Rosgen wrote:
> > In a game I am playing, we encountered a bug in 1.4.2 that is not in
1.4.1.
> >  Specifically, there is a company with the D private, which allows
> > free tiles to be laid in the mountains (in rails XML, these tile lays
> > are free="yes" and extra="no").  The attached .rails file exhibits the
> > problem: Brad's TR does not get offered a free tile lay in F5.
> >
> > Tracking the problem down lead to the method getSpecialTileLays in
> > OperatingRound: when testing to see if special tile lays with extra="no"
> > are possible, this method checks to see if the tile specified in the
> > SpecialTileLay can be laid.  Unfortunately in the 1889 Private D is
> > not restricted to a specific tile, so the action wasn't being added to
> > the list.  The attached patch changes this to a different (and I think
> > equivalent?) method of testing if normal tile lays are still available
> > -- I check that the map tileLaysPerColour is not empty (as is done by
> > the method areTileLaysPossible when it tests if normal tile lays are
> > available).
> >
> > It is not clear to me that this is the best solution.  Other solutions
> > might be:
> >
> > 1) Add three SpecialTileLays to Private D in 1889, one for each
> > available tile (7,8,9, in this case) 2) Change SpecialTileLay to keep
> > a list of available tiles, with corresponding changes to
> > OperatingRound and LayTile
> > 3) If the tile in SpecialTileLay is null, treat this as no restriction:
> > get the lists of all available tiles in the restricted hexes and check
> > to see if any of them are valid, adding LayTile actions as appropriate.
> >
> > Bill Rosgen
> 
> 
>
----------------------------------------------------------------------------
--
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel