rails-devel — List for discussion of Rails development

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

On Wed, Apr 30, 2014 at 9:34 AM, brett lentz <bre...@gm...> wrote:

> The main reason I chose SVG, was because it meant that we weren't tied to
> just using Swing for our UI. Way back in the early days of the project,
> Erik did some very preliminary prototyping to demonstrate that a web-based
> UI was also possible and even desirable.
>

I'm not positive SVG is the way to go for a web-based app - personally, I
would probably use sprited images downloaded from the server.  Particularly
if you are going to reuse the Java codebase and compile with GWT, as you
get the compile-time spriting for free.

I still believe that supporting the potential for more than the current
> Swing UI is nice-to-have. But, I think a flexible tile definition that can
> be used to render the tiles in a desire format also fits that requirement
> just as easily as using SVG for the tile graphics themselves.
>

The rendering API that would have to be implemented is things like arcs,
circles, transformed text, etc, so you should be able to draw it using
Java2D or SVG or pretty much anything with basic drawing APIs.

-- 
John A. Tamplin

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

On Wed, Apr 30, 2014 at 5:41 AM, Stefan Frey <ste...@we...> wrote:

> John:
> Thanks for your recommendations. Some quick comments below.
> Your comments are always helpful, so feel free to share your thoughts.
> Stefan
>
> > I wouldn't have kept the .18t file format with its painful conventions
> > for one.
>
> Yes that will be replaced by Tiles.xml, which is much nicer to write.
>
> >
> > For another, I would have separated tile layout from tile drawing, and
> > supported the tile definition either using the high-level approach of
> > "the city is here, and it is connected to these locations" and letting
> > the layout be generated, or allow you to specify the layout (exact
> > positions, rotations, etc) - as it, especially on crowded tiles, I had
> > to do special-case layout things and it still isn't great.  I would have
> > also generalized the track layout to build bezier curves directly rather
> > than keeping all the special-case code for "if this position is
> > connected to this position, draw it this way".
>
> Most likely I will follow your recommendation to separate track
> configuration from tile drawing hints (where to position stations etc.).
>
> I even consider making another step: Allow parametrized tiles, tiles
> that use the same track layout, but differ in the station values and
> labels: Currently a new tile is defined any time the station value
> changes and/or a label is added to the tile.
>
> One could even consider the tile color to be a parameter of the tile and
> thus there is no need to duplicate the track layout definition only
> because the color changes.
>
> For sure they are different tiles that are required for a physical game,
> but not if they get generated automatically.
>
> One thing that we still want to support is a (visible to the user)
> tile-id that is identical to the 18xx tiles database and used for the
> boardgame.
>
> >
> >     And: You are right, writing to Swing is an option.
> >     However I expect that any suitable Java svg libraries with support
> for
> >     Swing allow the creation of a svg file by writing to a Graphics2D
> >     object. So if java as the implementation language switching from svg
> to
> >     direct painting will be nearly transparent.
> >
> >
> > Let's just say I am skeptical of using an API designed for drawing on
> > the screen and getting good results generating SVG from it, but feel
> > free to go that route if you prefer.
> >
> > --
>
> I agree with your sentiment. It seems odd to first create SVG via a
> Swing API dynamically and then convert the SVG back into Swing graphics.
> But this might be true only for the time being. Later on Rails graphics
> might be produced by another GUI library than Swing and/or the graphic
> shown is generated by a different SVG library, that uses a different API
> for creation. And given the current situtation I do not want to be tied
> to Swing.
>
> However all existing Java svg libraries create SVG files from Java via
> the Swing Graphics API. I wonder how this is solved by other languages.
> Is doubt that operating on the SVG via XML DOM is preferable.
> I would prefer an API similar to the javascript library
> http://raphaeljs.com/ .
>
> Given the fact that Java 6 ships JS support via the Rhino engine, and
> Java 8 comes with a brand-new JS engine (Nashorn), most likely raphaeljs
> is the way to go.
>
>
The main reason I chose SVG, was because it meant that we weren't tied to
just using Swing for our UI. Way back in the early days of the project,
Erik did some very preliminary prototyping to demonstrate that a web-based
UI was also possible and even desirable.

I still believe that supporting the potential for more than the current
Swing UI is nice-to-have. But, I think a flexible tile definition that can
be used to render the tiles in a desire format also fits that requirement
just as easily as using SVG for the tile graphics themselves.

---Brett.

Re: [Rails-devel] 1862 development starting back up

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

My approach is similar to Martins, for the same reasons (working on 
different machines):

So I use my "private" branches (all those prefixed with sfy_) in the 
rails repos mainly for backup and synch. However it also allows others 
to have a glance how things develop.

The "official" branches (for rails 2.0 currently only rails_2_develop) 
are updated as soon as I have finished a new feature and compiles and 
runs all automated tests without an error.

For bug-fixes I usually create only a short lived branch on my local 
machine and then merge it quickly into the official branches.

This would also be my recommendation for others:
Create "private" branches for new features and prefix them with your own 
initials and push them to the official repo early and often.

As soon as you have finished something and want to add it to the central 
development merge it into rails_2_develop. Make sure that all tests are 
running. If you are not comfortable to merge yourself into Rails 2 at 
the beginning, you can always ask for my help.

Stefan


On 04/30/2014 07:41 AM, Dr. Martin Brumm wrote:
> I tend to push small pieces because i work on different systems (private
> pc at home, Laptop abroad)
>
>
> Von Samsung Mobile gesendet
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Michael Alexander
> Datum:30.04.2014 06:20 (GMT+01:00)
> An: "Development list for Rails: an 18xx game"
> Betreff: [Rails-devel] 1862 development starting back up
>
> At least for a little while, unless life decides to interfere again.  I
> have gone through the old mail notes, and it looks like where I should
> be basing things on rails_2_develop, is that correct?
>
> I have a tendency to want to push things back up to the repository on a
> pretty frequent basis.  Do we have a guideline for how often is
> reasonable?  Have other Rails developers generally been working
> privately on games and then pushing a large amount all at once?  Or is
> it usually small pieces at a time?
>
> Mike
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

John:
Thanks for your recommendations. Some quick comments below.
Your comments are always helpful, so feel free to share your thoughts.
Stefan

> I wouldn't have kept the .18t file format with its painful conventions
> for one.

Yes that will be replaced by Tiles.xml, which is much nicer to write.

>
> For another, I would have separated tile layout from tile drawing, and
> supported the tile definition either using the high-level approach of
> "the city is here, and it is connected to these locations" and letting
> the layout be generated, or allow you to specify the layout (exact
> positions, rotations, etc) - as it, especially on crowded tiles, I had
> to do special-case layout things and it still isn't great.  I would have
> also generalized the track layout to build bezier curves directly rather
> than keeping all the special-case code for "if this position is
> connected to this position, draw it this way".

Most likely I will follow your recommendation to separate track 
configuration from tile drawing hints (where to position stations etc.).

I even consider making another step: Allow parametrized tiles, tiles 
that use the same track layout, but differ in the station values and 
labels: Currently a new tile is defined any time the station value 
changes and/or a label is added to the tile.

One could even consider the tile color to be a parameter of the tile and 
thus there is no need to duplicate the track layout definition only 
because the color changes.

For sure they are different tiles that are required for a physical game, 
but not if they get generated automatically.

One thing that we still want to support is a (visible to the user) 
tile-id that is identical to the 18xx tiles database and used for the 
boardgame.

>
>     And: You are right, writing to Swing is an option.
>     However I expect that any suitable Java svg libraries with support for
>     Swing allow the creation of a svg file by writing to a Graphics2D
>     object. So if java as the implementation language switching from svg to
>     direct painting will be nearly transparent.
>
>
> Let's just say I am skeptical of using an API designed for drawing on
> the screen and getting good results generating SVG from it, but feel
> free to go that route if you prefer.
>
> --

I agree with your sentiment. It seems odd to first create SVG via a 
Swing API dynamically and then convert the SVG back into Swing graphics.
But this might be true only for the time being. Later on Rails graphics 
might be produced by another GUI library than Swing and/or the graphic 
shown is generated by a different SVG library, that uses a different API 
for creation. And given the current situtation I do not want to be tied 
to Swing.

However all existing Java svg libraries create SVG files from Java via 
the Swing Graphics API. I wonder how this is solved by other languages. 
Is doubt that operating on the SVG via XML DOM is preferable.
I would prefer an API similar to the javascript library 
http://raphaeljs.com/ .

Given the fact that Java 6 ships JS support via the Rhino engine, and 
Java 8 comes with a brand-new JS engine (Nashorn), most likely raphaeljs 
is the way to go.

Re: [Rails-devel] 1862 development starting back up

[Dr. M. B. <dr....@t-...>]

I tend to push small pieces because i work on different systems (private pc at home, Laptop abroad)


Von Samsung Mobile gesendet

-------- Ursprüngliche Nachricht --------
Von: Michael Alexander <out...@gm...> 
Datum:30.04.2014  06:20  (GMT+01:00) 
An: "Development list for Rails: an 18xx game" <rai...@li...> 
Betreff: [Rails-devel] 1862 development starting back up 

At least for a little while, unless life decides to interfere again.  I have gone through the old mail notes, and it looks like where I should be basing things on rails_2_develop, is that correct?

I have a tendency to want to push things back up to the repository on a pretty frequent basis.  Do we have a guideline for how often is reasonable?  Have other Rails developers generally been working privately on games and then pushing a large amount all at once?  Or is it usually small pieces at a time?

Mike

[Rails-devel] 1862 development starting back up

[Michael A. <out...@gm...>]

At least for a little while, unless life decides to interfere again.  I
have gone through the old mail notes, and it looks like where I should be
basing things on rails_2_develop, is that correct?

I have a tendency to want to push things back up to the repository on a
pretty frequent basis.  Do we have a guideline for how often is reasonable?
 Have other Rails developers generally been working privately on games and
then pushing a large amount all at once?  Or is it usually small pieces at
a time?

Mike

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, April 26, 2014 3:57 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Design Question regarding Minors/Majors
> [corrected]
> 
> We differ in the fact that I prefer composition over inheritance for
companies
> in Rails. However please feel free to adopt your favorite style of coding
for
> your implementation. I am sure that for example Erik for example would
> prefer your approach over mine ;-)

If so, that would probably be more a consequence of not knowing any better
than anything else.  
When I started working on Rails (after Brett's initial work), I had got
neither much education nor much experience with Java, and so I had to invent
strategies mainly on my own
(many discussions with Brett notwithstanding. The XML processing approach
through the ConfigurableComponentI interface is from Iain Adams).  
 
> One detailed comment:
> My proposals were for XML templates, it did not imply creating new Java
> classes. XML company templates are much more lightweight than new
> classes.

I fully agree with that. One other consideration I have always tried to
adhere to was to keep the number of classes and class types as low as
reasonably possible, in order not to get lost in the kind of jungle that I
later noticed in another (and quite different) project. 
But by now I fully leave it to you all, and in particular Stefan, to decide
how to proceed. The composition approach does look attractive to me.
 
> Except from that I fully agree with your proposal, however it would be
great
> if you were able to include 1856 (and current prototypes 1826,
> 18Scan?) into your analysis of nationalization?

The 18Scan SJ merger is predefined and thus resembles the 1835/37 mergers. I
think the main difference is that everything occurs at once.

Erik

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

Seems like that calls for another CreationStrategy implementation:
ForcedMerger versus FreeformMerger.

 From my experience now I prefer naming the classes in the core engine 
avoiding references to specific 18xx, as most of the time it requires 
knowing the title. So I prefer MergerCompany to NationalCompany.

As the company templates defined in CompanyManager.xml are game 
specific, they can define game specific wording.

Example: You have the PrivateCompany class, but define in 
CompanyManager.xml for 1837, that private companies are called Mountain 
Railways.

>
> Those games' mergers are very similar to each other, but not to 1835/37
> (not only no reserved shares, but no predetermination of what companies
> will merge).  So I think they should have their own class rather than be
> included in the one I've called NationalCompany -- but maybe I should
> use some other name, since CGR and Etat/SNCF are national companies too.
>
>

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

On 2014-04-26 06:56, Stefan Frey wrote:
> John:
> I agree with the content of your proposal.
> 
> We differ in the fact that I prefer composition over inheritance for 
> companies in Rails.

I am an old C++ programmer and think that way, but I'm willing to use
interfaces rather than inheritance if it makes things easier for you.
I haven't yet read the page you cited, but I will.

> My favorite structure would be do define the following interfaces (or 
> before Java 8 abstract classes):
> 
> CompanyOwnership
> CompanyOperation
> CompanyCreation
> 
> Concrete implementations would be e.g. PrivateOwnership and 
> PublicOwnership, TrainRunning and FixedDividend and 
> CreationByNationalization, CreationByMerger and CreationByIPO.
> 
> which when allow to define only one company class and then set the 
> ownership, operation and creation behavior accordingly.

I like that idea too.

> One detailed comment:
> My proposals were for XML templates, it did not imply creating new Java 
> classes. XML company templates are much more lightweight than new classes.

I have noticed both techniques in the code, but am still figuring out
how they interact.

> Except from that I fully agree with your proposal, however it would be 
> great if you were able to include 1856 (and current prototypes 1826, 
> 18Scan?) into your analysis of nationalization?

Those games' mergers are very similar to each other, but not to 1835/37
(not only no reserved shares, but no predetermination of what companies
will merge).  So I think they should have their own class rather than be
included in the one I've called NationalCompany -- but maybe I should
use some other name, since CGR and Etat/SNCF are national companies too.

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

John:
I agree with the content of your proposal.

We differ in the fact that I prefer composition over inheritance for 
companies in Rails. However please feel free to adopt your favorite 
style of coding for your implementation. I am sure that for example Erik 
for example would prefer your approach over mine ;-)

The basic idea is discussed here:
http://en.wikipedia.org/wiki/Composition_over_inheritance

I can see that major areas for which companies can differ in 18xx are:
- Ownership: public, private
- Operation: runTrains, fixedDividends
- Creation: nationalization, merger, ipo

Assume that all types of companies might exist, inheritance requires 
2*2*3 = 12 classes of companies. (e.g. 1830 has PublicTrainRunningIPO
and PrivateFixedDividendsIPO companies, 1835 adds PrivateTrainRunningIPO 
(minor) companies, PublicTrainRunningNationalization (PR) company).

My favorite structure would be do define the following interfaces (or 
before Java 8 abstract classes):

CompanyOwnership
CompanyOperation
CompanyCreation

Concrete implementations would be e.g. PrivateOwnership and 
PublicOwnership, TrainRunning and FixedDividend and 
CreationByNationalization, CreationByMerger and CreationByIPO.

which when allow to define only one company class and then set the 
ownership, operation and creation behavior accordingly.

In the long run (as soon as we arrive at Java 8) it will be possible to 
switch to interfaces, which makes this approach even more attractive.

One detailed comment:
My proposals were for XML templates, it did not imply creating new Java 
classes. XML company templates are much more lightweight than new classes.

Except from that I fully agree with your proposal, however it would be 
great if you were able to include 1856 (and current prototypes 1826, 
18Scan?) into your analysis of nationalization?

Stefan


>
> 1. Generalize the code that handles Prussian formation (and mergers
> into it) in 1835, so that there can be more than one "Prussian".
> This involves creating a new class, NationalCompany, which has the
> property that some of its share certificates are reserved to be
> exchanged for the various companies that will eventually merge into
> it.
>
> A NationalCompany is a PublicCompany with these additional properties.
> *  A list of the other companies (of any kind) which will merge, and
> the shares to be exchanged for each.  If any of the predecessors is a
> public company then there must be an exchange certificate for each one
> of its share certificates.
> *  The game phase that begins the period in which the NationalCompany
> may form.  (The predecessor that converts to the president's share is,
> by definition, the one that may form it.)
> *  The game phase at which the NationalCompany must form.
> *  The game phase at which all predecessors of the NationalCompany must
> merge.
>
> [Two important notes here.  (a) Two or even all three of these phases
> may be the same, thus forcing the NationalCompany to form and merge all
> its predecessors at once.  SD does this in 1837.  (b) If more than one
> NationalCompany is giving the same player repeated opportunities to
> form it or merge predecessors into it, that player should see only one
> dialog box with these choices each round -- not one for each minor or
> even each NationalCompany.  That would be too much clutter.]
>
> *  A boolean which if true, means that when all non-reserved shares of
> the NationalCompany are out of the IPO, all predecessors of the
> NationalCompany must merge at the end of that stock round.  (Thus I can
> use this class, not only for the three state railways in 1837, but also
> for most of its other public companies -- to handle the coal companies
> that will merge into each one).
>
> The existing XML interface that handles the definitions of companies
> should be expanded to cover these properties.
>
> Once the above is tested and working, it should probably be used by 1835
> (and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
> belonging in gamespecific_1837.
>
> [For grins I may even include the capability to have a predecessor
> "decide" that it'll never merge after all, thus moving its reserved
> trade-in share of the NationalCompany into the regular IPO.  This would
> handle the growth companies in 2038.]
>
> 2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
> be changed here, but I want the companies to have a couple of new
> properties.  One is that a MinorCompany_1837 can have multiple shares.
> (I want to handle U1 and U3 this way because most of the differences
> between the existing public and minor company classes relate to the fact
> that PublicCompany shares can be sold, and therefore have a market price.
> U1 and U3 can't and don't.)  The other new property is that certain minor
> companies (the coal companies) can only own certain types of trains.
>
> As with #1, the XML interface that handles definitions of companies
> should be expanded to cover these properties.
>
> 3. Generalize the start-round code.  1837 has two start packets: one
> where you're buying companies (or a private company plus a share, as in
> 1835) from the top of any column in a 3-column table.  Then when that
> sells out, the minor companies of KK and UG form a second "start packet"
> where you can buy anything (but not the non-president's share of U1 or
> U3 before the president's share).
>
> Someone wrote that Rails can now handle a second start packet, but I
> haven't gone through that section of the code since it changed.
>
> [Yes, I know, Steve Thomas says that there is about to be a new edition
> of 1837 using the very different start-packet he uses in his PBEM games.
> I do plan to accommodate that, but I refuse to make it the only way to
> play the game, because I think it ruins the game.]
>
> * * *
>
> Once that laundry list is done, the company types become roughly this.
>
> Mountain railways -> PrivateCompany.  No need to even call them
> anything else.  Of course the special-power ability
>
> Coal and Minor companies -> MinorCompany_1837.
>
> Major companies, including State companies -> all NationalCompany, except
>     the one (GT, IIRC) which has no coal company that merges into it.
>     That one is just a PublicCompany.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

On Sat, Apr 26, 2014 at 8:56 AM, Stefan Frey <ste...@we...> wrote:

> Question: Is there anything you might have done different in hindsight?
>

I wouldn't have kept the .18t file format with its painful conventions for
one.

For another, I would have separated tile layout from tile drawing, and
supported the tile definition either using the high-level approach of "the
city is here, and it is connected to these locations" and letting the
layout be generated, or allow you to specify the layout (exact positions,
rotations, etc) - as it, especially on crowded tiles, I had to do
special-case layout things and it still isn't great.  I would have also
generalized the track layout to build bezier curves directly rather than
keeping all the special-case code for "if this position is connected to
this position, draw it this way".


> And: You are right, writing to Swing is an option.
> However I expect that any suitable Java svg libraries with support for
> Swing allow the creation of a svg file by writing to a Graphics2D
> object. So if java as the implementation language switching from svg to
> direct painting will be nearly transparent.
>

Let's just say I am skeptical of using an API designed for drawing on the
screen and getting good results generating SVG from it, but feel free to go
that route if you prefer.

-- 
John A. Tamplin

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

John: Thanks a lot for your code. Great reference.

Question: Is there anything you might have done different in hindsight?

And: You are right, writing to Swing is an option.
However I expect that any suitable Java svg libraries with support for 
Swing allow the creation of a svg file by writing to a Graphics2D 
object. So if java as the implementation language switching from svg to 
direct painting will be nearly transparent.

Stefan

On 04/26/2014 02:09 PM, John A. Tamplin wrote:
> On Tue, Apr 22, 2014 at 8:09 PM, brett lentz <bre...@gm...
> <mailto:bre...@gm...>> wrote:
>
>     If you're willing to contribute your Perl and/or Java code under the
>     GPL v2+ license that Rails uses, we can probably make use of it.
>     Posting the code to the list is a reasonable way to start.
>
>
> Attached is my perl code and sample data.  Of course the files reference
> fonts that I own but can't redistribute - it should be easy enough to
> substitute them (and you probably don't care so much about the fonts for
> on-screen use).  You are free to redistribute it (or any derived work)
> under any open-source license you like if it is useful to you.
>   Initially the perl was pretty much a direct port of the Delphi code,
> but of course it diverged significantly from there as I changed it to
> meet my requirements.
>
> To add SVG support to the existing code, you would want to write an SVG
> subclass of RenderTile similar to RenderTilePS.  Note that there is a
> lot of PS used in various places, such as annotations on tiles, that you
> would also have to find some way of representing.  Also, I'm not sure
> how you would deal with the text metrics stuff to layout the text
> properly, but again maybe you don't care if it isn't perfect.
>
> Instead of SVG, you could also have a Swing renderer implementation and
> cut out the extra step if you liked.
>
> --
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1870

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

Volker: You are right, however this is implemented in Rails, as other 
games already supported by Rails share this feature (1851, 18EU).
But most likely there are other bits I have not mentioned.
Stefan

On 04/25/2014 02:27 PM, Schnell, Volker wrote:
> One point is also missing: the Companys can buy shares and redeem them.
> Volker

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

My own thoughts on this topic:

* The important contribution of Marcos Tile Designer is not so much the 
UI tool itself, but the Tile definitions in file "TileDictionary.18t".

* The process from "TileDictionary.18t" to the game specifics 
"Tiles.xml" is detailed here:

https://sourceforge.net/apps/mediawiki/rail/index.php?title=Tile_creation

* Access to Marcos and Johns code would be really helpful to avoid 
re-inventing the wheel again. I will send Marco an e-mail if he allows 
us to take a look at it. John, if you would share the code, it would be 
great. Maybe you could send it to one of the admins (Brett or myself)?

* My proposal is to define tiles manually using the syntax we already 
have in Tiles.xml (instead of the one used in .18t, but keep in mind 
that this is only a different syntax to Marco, the content is identical).

Take the example of tile 57 (straight city):

<Tile colour="yellow" id="57" name="57">
	<Station id="city1" position="0" slots="1" type="City" value="20"/>
	<Track from="city1" gauge="normal" to="side3"/>
	<Track from="city1" gauge="normal" to="side0"/>
</Tile>

This contains all information needed to generate a SVG from it.
As John said this only requires rules for tracks/cities/token slots.

By adopting different styles it would even be possible to support 
different layouts based on the same definitions.

* For Rails 2.0 I have already simplified the handling of svg to some 
extent. My intention is to replace the current svg library (batik) by 
one which has a smaller footprint, is simpler to use and compatible
with Android and/or JavaFX. Most likely this will happen at 2.1 / 2.2.
However this is no precondition for a own svg-engine.

* Some simplification of the map display code was done as well (mainly 
by factoring out code into MapOrientation class). However I still intend 
to refactor that even more. Again this is no precondition, but it a own 
SVG engine would really be helpful to make map painting easier. 
Currently the SVG tiles and the map code exist in two different worlds, 
loosely speaking ;-)

* Hand-made graphics should be the exception and should be defined in 
plain svg. Most vector graphic programs (including inkscape) are able to 
save in "plain" svg, instead in their more bloated own svg based format.

Question is if there is someone who would like to implement a tile to 
svg engine for Rails? It requires no detailed knowledge of any 18xx 
game, however some Java/svg/xml experience.

I can offer my help and as mentioned some time ago, I have a duplicate 
version of 
http://www.amazon.com/SVG-Unleashed-Andrew-H-Watt/dp/0672324296 that I 
am willing to ship free-of-charge to a volunteer.
The book is not perfect by any means, but I like it is a reference.

However the available documentation on svg on the net covers every 
aspect needed for the task.

If no one else is interested, it will be on my own list of to-dos after 
rails 2.0 is out.

Stefan

On 04/23/2014 02:09 AM, brett lentz wrote:
>
> On Tue, Apr 22, 2014 at 10:52 AM, John A. Tamplin <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>
>     On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm...
>     <mailto:bre...@gm...>> wrote:
>
>         That's a tricky issue. It would be really nice if TileDesigner
>         were open sourced, so that we could update it.
>
>
>     Hmm, it's not?  At least Marco sent it to me when I asked.
>
>
> Unless the code has an explicit OSS license assigned that's compatible
> with the license used by Rails, we can't really use Marco's code even if
> you have it.
>
>     However, it is written in Delphi.  For my use, I reimplemented it in
>     perl, and that is still what I use to generate the production tiles.
>       Of course, the goals for printing are different than for screen
>     (and I made a number of changes to be able to generate print-ready
>     output and more complex tiles), but I generate PostScript from the
>     tile definitions and SVG wouldn't be hard (basically at the
>     rendering stage you have methods for drawing an arc, circle, etc).
>
>
> Yep. Jumping from Postscript to SVG is pretty easy. IIRC, Perl has
> GSAPI, which hooks into Ghostscript and can do that heavy-lifting.
>
>
>     Several years ago I started porting it to Java for use in Rails, but
>     I didn't have time to finish it.  If someone wants to take that
>     and/or the perl code and modify I would be happy to send what I have
>     (assuming I can find the Java port :).
>
>
> If you're willing to contribute your Perl and/or Java code under the GPL
> v2+ license that Rails uses, we can probably make use of it. Posting the
> code to the list is a reasonable way to start.
>
>         It might be possible to develop some SVG templates for each of
>         the components of a tile. That would allow us to assemble new
>         tiles in Inkscape using a standardized set of primitives on a
>         standardized image base.
>
>
>     I don't think you want to get in the business of hand-drawing tiles.
>       Aside from consistency issues, you will also have to redraw every
>     single tile if you decide to change some aspect - I think generating
>     them from some tile description is the way to go.
>
>
> I agree. It's not ideal, but implementing our own tile drawing engine is
> also not very appealing. ;-)
>
> The nice thing about using SVG is that certain classes of problems are
> at least a non-issue, when compared to the bitmap-based tile sets.
>
>     --
>     John A. Tamplin
>
>
> ---Brett.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On 2014-04-25 19:34, Chris Shaffer wrote:
> 
> On Fri, Apr 25, 2014 at 7:11 PM, John David Galt <jd...@di... <mailto:jd...@di...>> wrote:
> 
>     A NationalCompany is a PublicCompany with these additional properties.
>     *  A list of the other companies (of any kind) which will merge, and
>     the shares to be exchanged for each.  If any of the predecessors is a
>     public company then there must be an exchange certificate for each one
>     of its share certificates.
>     *  The game phase that begins the period in which the NationalCompany
>     may form.  (The predecessor that converts to the president's share is,
>     by definition, the one that may form it.)
>     *  The game phase at which the NationalCompany must form.
>     *  The game phase at which all predecessors of the NationalCompany must
>     merge.
> 
> 
> I would encourage you to look at games like 18MEX, which don't quite fit this model. It would be nice if your new model would fit those games as well. In 18MEX, there are three minor companies which merge into two different major companies. Minors A and B merge into the NdM national railroad in exchange for 5% shares. Minor C merges into the UdY, which in all other respects is a regular major company. Further, shares of the NdM are distributed as:
> 
> 1) President 20% auctioned as a private company.
> 2) Six 10% shares may be purchased in stock rounds after phase 3.5 begins (on the sale of the fifth 3 train).
> 3) Two 5% shares exchanged for minor companies A and B when phase 3.5 begins.
> 4) One 10% share that can optionally be exchanged for the president's share of one of the CHI, MC, MEX, SPM, or UdY major company on the sale of the first 5 train.
> 
> The rules for 18MEX are available on the Deep Thought Games web site.

That's a good reason to generalize this bit:
>> [For grins I may even include the capability to have a predecessor
>> "decide" that it'll never merge after all, thus moving its reserved
>> trade-in share of the NationalCompany into the regular IPO.  This would
>> handle the growth companies in 2038.]
to allow a share to be "reserved" while putting off the decision of which
company gets to convert to it until a later phase.  I'll add that to my
class definition.

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On Fri, Apr 25, 2014 at 7:11 PM, John David Galt <
jd...@di...> wrote:

> A NationalCompany is a PublicCompany with these additional properties.
> *  A list of the other companies (of any kind) which will merge, and
> the shares to be exchanged for each.  If any of the predecessors is a
> public company then there must be an exchange certificate for each one
> of its share certificates.
> *  The game phase that begins the period in which the NationalCompany
> may form.  (The predecessor that converts to the president's share is,
> by definition, the one that may form it.)
> *  The game phase at which the NationalCompany must form.
> *  The game phase at which all predecessors of the NationalCompany must
> merge.
>

I would encourage you to look at games like 18MEX, which don't quite fit
this model. It would be nice if your new model would fit those games as
well. In 18MEX, there are three minor companies which merge into two
different major companies. Minors A and B merge into the NdM national
railroad in exchange for 5% shares. Minor C merges into the UdY, which in
all other respects is a regular major company. Further, shares of the NdM
are distributed as:

1) President 20% auctioned as a private company.
2) Six 10% shares may be purchased in stock rounds after phase 3.5 begins
(on the sale of the fifth 3 train).
3) Two 5% shares exchanged for minor companies A and B when phase 3.5
begins.
4) One 10% share that can optionally be exchanged for the president's share
of one of the CHI, MC, MEX, SPM, or UdY major company on the sale of the
first 5 train.

The rules for 18MEX are available on the Deep Thought Games web site.

--
Chris

*Warning! NSA analysts could be reading this email. And because there's
hardly any accountability, we have no idea how they may use it. If that
bothers you, click here to do something about it.
<https://www.aclu.org/secure/stopnsa>*

Re: [Rails-devel] Design Question regarding Minors/Majors [corrected]

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

Sorry, I hit Send too soon.

On 2014-04-24 23:57, Stefan Frey wrote:
> Martin & John:
> some comments about how to answer the questions:
> 
> There are two classes of companies defined by the Java code:
> 
> PrivateCompany (inherits from Company and Certificate)
> => Only pays dividends
> => Ownership direct by one player
> 
> PublicCompany (inherits from Company):
> => Operate trains
> => Ownership via shares
> 
> So this implies that currently all operating companies have to be public 
> companies. This explains why the minors in 1835 have to be public 
> companies with one 100% share.
> 
> Then it is allowed to use "company templates" in CompanyManager.xml to 
> avoid repeating common attributes for companies.
> 
> So in my opinion 1837 the following templates should be defined:
> 
> * Mountain Railways (based on PrivateCompany)
> * Coal Railways (based on PublicCompany with 1 100% share)
> 
> * Südbahnen (based on PublicCompany with 1 100% share)
> * K&K Bahnen (based on PublicCompany with 1 100% share)
> * Ungarische (based on PublicCompany)
> 
> * Nationals (based on PublicCompany)
> * Majors (based on PublicCompany)

I have a somewhat simpler architecture in mind.  However, my design
doesn't start there, but with the detailed things that 1837 needs and
the existing Rails code can't do.  So I'll begin, more or less, with
my to-do list.

1. Generalize the code that handles Prussian formation (and mergers
into it) in 1835, so that there can be more than one "Prussian".
This involves creating a new class, NationalCompany, which has the
property that some of its share certificates are reserved to be
exchanged for the various companies that will eventually merge into
it.

A NationalCompany is a PublicCompany with these additional properties.
*  A list of the other companies (of any kind) which will merge, and
the shares to be exchanged for each.  If any of the predecessors is a
public company then there must be an exchange certificate for each one
of its share certificates.
*  The game phase that begins the period in which the NationalCompany
may form.  (The predecessor that converts to the president's share is,
by definition, the one that may form it.)
*  The game phase at which the NationalCompany must form.
*  The game phase at which all predecessors of the NationalCompany must
merge.

[Two important notes here.  (a) Two or even all three of these phases
may be the same, thus forcing the NationalCompany to form and merge all
its predecessors at once.  SD does this in 1837.  (b) If more than one
NationalCompany is giving the same player repeated opportunities to
form it or merge predecessors into it, that player should see only one
dialog box with these choices each round -- not one for each minor or
even each NationalCompany.  That would be too much clutter.]

*  A boolean which if true, means that when all non-reserved shares of
the NationalCompany are out of the IPO, all predecessors of the
NationalCompany must merge at the end of that stock round.  (Thus I can
use this class, not only for the three state railways in 1837, but also
for most of its other public companies -- to handle the coal companies
that will merge into each one).

The existing XML interface that handles the definitions of companies
should be expanded to cover these properties.

Once the above is tested and working, it should probably be used by 1835
(and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
belonging in gamespecific_1837.

[For grins I may even include the capability to have a predecessor
"decide" that it'll never merge after all, thus moving its reserved
trade-in share of the NationalCompany into the regular IPO.  This would
handle the growth companies in 2038.]

2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
be changed here, but I want the companies to have a couple of new
properties.  One is that a MinorCompany_1837 can have multiple shares.
(I want to handle U1 and U3 this way because most of the differences
between the existing public and minor company classes relate to the fact
that PublicCompany shares can be sold, and therefore have a market price.
U1 and U3 can't and don't.)  The other new property is that certain minor
companies (the coal companies) can only own certain types of trains.

As with #1, the XML interface that handles definitions of companies
should be expanded to cover these properties.

3. Generalize the start-round code.  1837 has two start packets: one
where you're buying companies (or a private company plus a share, as in
1835) from the top of any column in a 3-column table.  Then when that
sells out, the minor companies of KK and UG form a second "start packet"
where you can buy anything (but not the non-president's share of U1 or
U3 before the president's share).

Someone wrote that Rails can now handle a second start packet, but I
haven't gone through that section of the code since it changed.

[Yes, I know, Steve Thomas says that there is about to be a new edition
of 1837 using the very different start-packet he uses in his PBEM games.
I do plan to accommodate that, but I refuse to make it the only way to
play the game, because I think it ruins the game.]

* * *

Once that laundry list is done, the company types become roughly this.

Mountain railways -> PrivateCompany.  No need to even call them
anything else.  Of course the special-power ability

Coal and Minor companies -> MinorCompany_1837.

Major companies, including State companies -> all NationalCompany, except
   the one (GT, IIRC) which has no coal company that merges into it.
   That one is just a PublicCompany.

Re: [Rails-devel] Design Question regarding Minors/Majors

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

On 2014-04-24 23:57, Stefan Frey wrote:
> Martin & John:
> some comments about how to answer the questions:
> 
> There are two classes of companies defined by the Java code:
> 
> PrivateCompany (inherits from Company and Certificate)
> => Only pays dividends
> => Ownership direct by one player
> 
> PublicCompany (inherits from Company):
> => Operate trains
> => Ownership via shares
> 
> So this implies that currently all operating companies have to be public 
> companies. This explains why the minors in 1835 have to be public 
> companies with one 100% share.
> 
> Then it is allowed to use "company templates" in CompanyManager.xml to 
> avoid repeating common attributes for companies.
> 
> So in my opinion 1837 the following templates should be defined:
> 
> * Mountain Railways (based on PrivateCompany)
> * Coal Railways (based on PublicCompany with 1 100% share)
> 
> * Südbahnen (based on PublicCompany with 1 100% share)
> * K&K Bahnen (based on PublicCompany with 1 100% share)
> * Ungarische (based on PublicCompany)
> 
> * Nationals (based on PublicCompany)
> * Majors (based on PublicCompany)

I have a somewhat simpler architecture in mind.  However, my design
doesn't start there, but with the detailed things that 1837 needs and
the existing Rails code can't do.  So I'll begin, more or less, with
my to-do list.

1. Generalize the code that handles Prussian formation (and mergers
into it) in 1835, so that there can be more than one "Prussian".
This involves creating a new class, NationalCompany, which has the
property that some of its share certificates are reserved to be
exchanged for the various companies that will eventually merge into
it.

A NationalCompany is a PublicCompany with these additional properties.
*  A list of the other companies (of any kind) which will merge, and
the shares to be exchanged for each.  If any of the predecessors is a
public company then there must be an exchange certificate for each one
of its share certificates.
*  The game phase that begins the period in which the NationalCompany
may form.  (The predecessor that converts to the president's share is,
by definition, the one that may form it.)
*  The game phase at which the NationalCompany must form.
*  The game phase at which all predecessors of the NationalCompany must
merge.

[Two important notes here.  (a) Two or even all three of these phases
may be the same, thus forcing the NationalCompany to form and merge all
its predecessors at once.  SD does this in 1837.  (b) If more than one
NationalCompany is giving the same player repeated opportunities to
form it or merge predecessors into it, that player should see only one
dialog box with these choices each round -- not one for each minor or
even each NationalCompany.  That would be too much clutter.]

*  A boolean which if true, means that when all non-reserved shares of
the NationalCompany are out of the IPO, all predecessors of the
NationalCompany must merge at the end of that stock round.  (Thus I can
use this class, not only for the three state railways in 1837, but also
for most of its other public companies -- to handle the coal companies
that will merge into each one).

The existing XML interface that handles the definitions of companies
should be expanded to cover these properties.

Once the above is tested and working, it should probably be used by 1835
(and 18Mex, and maybe someday 2038, etc...) Thus I don't see it as
belonging in gamespecific_1837.

[For grins I may even include the capability to have a predecessor
"decide" that it'll never merge after all, thus moving its reserved
trade-in share of the NationalCompany into the regular IPO.  This would
handle the growth companies in 2038.]

2. Generalize MinorCompany_1835 to MinorCompany_1837.  Not much needs to
be changed here, but I want the companies to have a couple of new
properties.  One is that a MinorCompany_1837 can have multiple shares.
(I want to handle U1 and U3 this way because most of the differences
between the existing public and minor company classes relate to the fact
that PublicCompany shares can be sold, and therefore have a market price.
U1 and U3 can't and don't.)  The other new property is that certain minor
companies (the coal companies) can only own certain types of trains.

As with #1, the XML interface that handles definitions of companies
should be expanded to cover these properties.

3. Generalize the start-round code.  1837 has two start packets: one
where you're buying companies (or a private company plus a share, as in
1835) from the top of any column in a 3-column table.  Then when that
sells out, the minor companies of KK and UG form a second "start packet"
where you can buy anything (but not the non-president's share of U1 or
U3 before the president's share).

Someone wrote that Rails can now handle a second start packet, but I
haven't gone through that section of the code since it changed.

* * *

Once that laundry list is done, the company types become roughly this.

Mountain railways -> PrivateCompany.  No need to even call them
anything else.

Coal and Minor companies -> MinorCompany_1837.

Major companies, including State companies -> all NationalCompany, except
   the one (GT, IIRC) which has no coal company that merges into it.
   That one is just a PublicCompany.

Re: [Rails-devel] Introducing Myself

[Michael A. <mic...@gm...>]

On Fri, Apr 25, 2014 at 7:01 AM, Stefan Frey <ste...@we...> wrote:

> Hi Mike,
> thanks a lot for your patch. A warm welcome to Rails devel.
>
> I have not tried your patch yet, however on first glance it should work.
> Usually it is not recommended to add such a check into one of the UI
> classes, as it breaks the UI/engine separation.
>
> The recommended solution is to not include the action in the set of
> possible actions that is sent to the UI.
> However in this case it is the only solution that avoids breaking old
> save files (which can still contain a pass in such situations).
>
> I intend to break backward-compatibility at e.g. Rails 2.1 or 2.2 to
> remove such fixes from the code and replace them by the better ones, so
> this will be included there.
>
> Question: I assume you still have to choose Pass manually, would it be
> possible to skip the player automatically and activate the next one?
> That would be optimal.
>

You do still have to choose pass manually - I think there is a good chance
that I could make it work the way you describe (and probably clean up the
UI/engine issue in the process). That said, from a user perspective, I feel
like I might click on a private to select, realize I can't bid upwards, and
then want to reconsider my choice. I could certainly use the undo
functionality for that, but clicking pass by hand seems like a good way to
allow that moment of consideration.

Then again, the existing code (with the bid button enabled) pops up a
warning to the user if you try to write a check that your bank account
can't handle. It may be that the reported bug is not something that you
want to act on at all.

Tonight after work I'll try to produce a patch that just performs the pass
action for you, and then the maintainers can decide what to do with it all.

-Mike


>
> Stefan
>
> On 04/25/2014 06:28 AM, Michael Anastasia wrote:
> > Hi all,
> >
> > I found rails via board game geek a few days ago. Unfortunately for me,
> > I'm not familiar with most of the titles that rails has already
> > implemented. Fortunately for me, my day job is programming in Java, and
> > I'm kind of excited about contributing to this project. I checked out
> > the repo the other day and decided to get my feet wet by trying my hand
> > at one of your open bugs. Attached is my attempt to fix ticket #133,
> > related to the initial auction in 18EU (which I chose because I actually
> > have played that title)
> >
> > If there are other specific bugs or features that you think I could help
> > with while getting my feet wet in the code base, please do let me know.
> > Alternatively, if there's a significant flaw in my submission, I'd love
> > to have your feedback.
> >
> > Nice to meet you,
> >
> > Mike Anastasia
> >
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> >
> >
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1870

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

One point is also missing: the Companys can buy shares and redeem them.
Volker
Am 25.04.2014 12:39, schrieb Stefan Frey:
> Gav:
> currently no one is working on 1870.
>
> Everything, what can be done via xml files, is already setup (map,
> companies).
>
> Main issues are the special properties of the privates, price protection
> during share rounds and destination runs.
>
> It requires some Java coding, but on a scala from easy to hard, it is of
> easy to medium difficulty. 1880 and 1862 for example are both hard in
> comparison.
>
> So if anyone is interested in finalizing 1870, can contact me. I would
> be happy to see 1870 implemented in Rails, it is one of my favorite 18xx.
>
> Stefan
>
>
> On 04/21/2014 11:44 AM, Gavin Cassells wrote:
>> Hi all,
>>
>> I know this is really cheeky as I am not a java developer, but I have
>> been following this list for some time and our group really loves all
>> the work ye have done.
>>
>> I am just wondering if anyone is still working on porting 1870 to rails?
>>
>> I know that some functionality was awaiting Rails 2.0.
>>
>> Any update I could get would be much appreciated by me and I am sure
>> many others.
>>
>> Thanks for all of the hard work guys,
>>
>> Gav
>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>>
>>
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Introducing Myself

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

Hi Mike,
thanks a lot for your patch. A warm welcome to Rails devel.

I have not tried your patch yet, however on first glance it should work. 
Usually it is not recommended to add such a check into one of the UI 
classes, as it breaks the UI/engine separation.

The recommended solution is to not include the action in the set of 
possible actions that is sent to the UI.
However in this case it is the only solution that avoids breaking old 
save files (which can still contain a pass in such situations).

I intend to break backward-compatibility at e.g. Rails 2.1 or 2.2 to 
remove such fixes from the code and replace them by the better ones, so 
this will be included there.

Question: I assume you still have to choose Pass manually, would it be 
possible to skip the player automatically and activate the next one?
That would be optimal.

Stefan

On 04/25/2014 06:28 AM, Michael Anastasia wrote:
> Hi all,
>
> I found rails via board game geek a few days ago. Unfortunately for me,
> I'm not familiar with most of the titles that rails has already
> implemented. Fortunately for me, my day job is programming in Java, and
> I'm kind of excited about contributing to this project. I checked out
> the repo the other day and decided to get my feet wet by trying my hand
> at one of your open bugs. Attached is my attempt to fix ticket #133,
> related to the initial auction in 18EU (which I chose because I actually
> have played that title)
>
> If there are other specific bugs or features that you think I could help
> with while getting my feet wet in the code base, please do let me know.
> Alternatively, if there's a significant flaw in my submission, I'd love
> to have your feedback.
>
> Nice to meet you,
>
> Mike Anastasia
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1870

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

Gav:
currently no one is working on 1870.

Everything, what can be done via xml files, is already setup (map, 
companies).

Main issues are the special properties of the privates, price protection 
during share rounds and destination runs.

It requires some Java coding, but on a scala from easy to hard, it is of 
easy to medium difficulty. 1880 and 1862 for example are both hard in 
comparison.

So if anyone is interested in finalizing 1870, can contact me. I would 
be happy to see 1870 implemented in Rails, it is one of my favorite 18xx.

Stefan


On 04/21/2014 11:44 AM, Gavin Cassells wrote:
> Hi all,
>
> I know this is really cheeky as I am not a java developer, but I have
> been following this list for some time and our group really loves all
> the work ye have done.
>
> I am just wondering if anyone is still working on porting 1870 to rails?
>
> I know that some functionality was awaiting Rails 2.0.
>
> Any update I could get would be much appreciated by me and I am sure
> many others.
>
> Thanks for all of the hard work guys,
>
> Gav
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Design Question regarding Minors/Majors

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

Martin & John:
some comments about how to answer the questions:

There are two classes of companies defined by the Java code:

PrivateCompany (inherits from Company and Certificate)
=> Only pays dividends
=> Ownership direct by one player

PublicCompany (inherits from Company):
=> Operate trains
=> Ownership via shares

So this implies that currently all operating companies have to be public 
companies. This explains why the minors in 1835 have to be public 
companies with one 100% share.

Then it is allowed to use "company templates" in CompanyManager.xml to 
avoid repeating common attributes for companies.

So in my opinion 1837 the following templates should be defined:

* Mountain Railways (based on PrivateCompany)
* Coal Railways (based on PublicCompany with 1 100% share)

* Südbahnen (based on PublicCompany with 1 100% share)
* K&K Bahnen (based on PublicCompany with 1 100% share)
* Ungarische (based on PublicCompany)

* Nationals (based on PublicCompany)
* Majors (based on PublicCompany)

An alternative approach is to combine the second block into a minor 
template and/or the third block into a major template.

However it might be easier to use the more granulate definition e.g. to 
ease the merger process.

Stefan

*** Remark:
In the long-run it is will be better to separate the concern of 
operating trains from the structure of ownership.

One possible implementation is to define only a single class of Company. 
At construction time it is possible to assign its type of operation and 
its ownership structure.

This would replace the object/inheritance approach by a 
entity/composition approach.



On 04/20/2014 04:55 PM, Martin Brumm wrote:
> Hello,
>
> in 1837 as some of you may know we have 3-4 different type of Minors
>
> The true Privates that just pay dividends, The Coal Train Companies
> (Kohlebahnen) that are only allowed to run specific trains and
> distribute the income 50/50 (1 share), the "Süd",KuK  which behave
> mostly like the Vorpreussen of 1835. And of course the Hungaries (U1, U3
> with 2 Shares each 25%), U2 (1 Share 50%).
>
> Whats your preference, suggestion etc. to handle the U1 and U3 ? Treat
> them as Majors ? or bring in a new class ?
>
> Regards
> Martin
>

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

On Tue, Apr 22, 2014 at 10:52 AM, John A. Tamplin <ja...@ja...> wrote:

> On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm...>wrote:
>
>> That's a tricky issue. It would be really nice if TileDesigner were open
>> sourced, so that we could update it.
>>
>
> Hmm, it's not?  At least Marco sent it to me when I asked.
>
>
Unless the code has an explicit OSS license assigned that's compatible with
the license used by Rails, we can't really use Marco's code even if you
have it.


> However, it is written in Delphi.  For my use, I reimplemented it in perl,
> and that is still what I use to generate the production tiles.  Of course,
> the goals for printing are different than for screen (and I made a number
> of changes to be able to generate print-ready output and more complex
> tiles), but I generate PostScript from the tile definitions and SVG
> wouldn't be hard (basically at the rendering stage you have methods for
> drawing an arc, circle, etc).
>

Yep. Jumping from Postscript to SVG is pretty easy. IIRC, Perl has GSAPI,
which hooks into Ghostscript and can do that heavy-lifting.


>
> Several years ago I started porting it to Java for use in Rails, but I
> didn't have time to finish it.  If someone wants to take that and/or the
> perl code and modify I would be happy to send what I have (assuming I can
> find the Java port :).
>

If you're willing to contribute your Perl and/or Java code under the GPL
v2+ license that Rails uses, we can probably make use of it. Posting the
code to the list is a reasonable way to start.


>
>
>> It might be possible to develop some SVG templates for each of the
>> components of a tile. That would allow us to assemble new tiles in Inkscape
>> using a standardized set of primitives on a standardized image base.
>>
>
> I don't think you want to get in the business of hand-drawing tiles.
>  Aside from consistency issues, you will also have to redraw every single
> tile if you decide to change some aspect - I think generating them from
> some tile description is the way to go.
>
>
I agree. It's not ideal, but implementing our own tile drawing engine is
also not very appealing. ;-)

The nice thing about using SVG is that certain classes of problems are at
least a non-issue, when compared to the bitmap-based tile sets.


> --
> John A. Tamplin
>
>
---Brett.

Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

On Tue, Apr 22, 2014 at 9:54 AM, brett lentz <bre...@gm...> wrote:

> That's a tricky issue. It would be really nice if TileDesigner were open
> sourced, so that we could update it.
>

Hmm, it's not?  At least Marco sent it to me when I asked.

However, it is written in Delphi.  For my use, I reimplemented it in perl,
and that is still what I use to generate the production tiles.  Of course,
the goals for printing are different than for screen (and I made a number
of changes to be able to generate print-ready output and more complex
tiles), but I generate PostScript from the tile definitions and SVG
wouldn't be hard (basically at the rendering stage you have methods for
drawing an arc, circle, etc).

Several years ago I started porting it to Java for use in Rails, but I
didn't have time to finish it.  If someone wants to take that and/or the
perl code and modify I would be happy to send what I have (assuming I can
find the Java port :).


> It might be possible to develop some SVG templates for each of the
> components of a tile. That would allow us to assemble new tiles in Inkscape
> using a standardized set of primitives on a standardized image base.
>

I don't think you want to get in the business of hand-drawing tiles.  Aside
from consistency issues, you will also have to redraw every single tile if
you decide to change some aspect - I think generating them from some tile
description is the way to go.

-- 
John A. Tamplin