rails-devel — List for discussion of Rails development

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

Nice idea, but I cannot find any ids in the SVG code (see attached example of tile 57 - reformatted and renamed as text).
And unfortunately we don't have any control over the SVG XML format, as we don't have the TileDesigner source code.

Getting an open source tile designer program may be one of our biggest needs.

Erik.

> -----Original Message-----
> From: Adam Badura [mailto:ab...@o2...]
> Sent: Thursday, August 18, 2011 11:49 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
> 
> And to fully benefit from the SVG model it would be great if the tile
> description had some mapping to SVG image of the tile. If for example
> station entry had an argument "svg-id" which would name identifier of SVG
> tile element which represents the station. Then the SVG map document
> code would not have to care that much about actual details of how the SVG
> makes the station (is it a single circle with border? or are those two circles of
> different radius wrapped in a an svg:g container? or whatever else...). It
> would know that it has to look for ID element and either replace it with
> station token element or to lay the station token element on the same
> position or whatever it likes. Yet it would be much easier.
> 
> Another example is marking routes. If a route from edge X to edge Y would
> be realized by ID1, ID2, ... IDn elements in SVG the code could just change
> style of those elements (for example change color to Train 1 color) and
> expect the route to be marked well.
> 
> If user clicks a station mark on SVG tile map manager will know ID of the
> "conceptual element" that was clicked and could easily in effect determine
> (based on the tile description) what was it. It easily transforms clicking "this
> white cirlce" into clicking NW station on a double station tile...
> 
> -----Oryginalna wiadomość-----
> From: Erik Vos
> Sent: Thursday, August 18, 2011 11:39 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
> 
> > -----Original Message-----
> > From: Adam Badura [mailto:ab...@o2...]
> > Sent: Thursday, August 18, 2011 12:20 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] batik and svg documents (was: Background
> > Maps)
> >
> > With SVG+XML I meant that (in my opinion) SVG should be used purly for
> > presentation. Tile "description" (like number of stations, track
> > connections between hex edges, stations on that tracks, and so on...)
> > should be stored separately (so not to mix different tile aspects).
> > This also allows to easly use different tile "styles" without need to
> > change code that analyzes runs or finds possible tile lays.
> 
> I fully agree with that.  Several games have hexes and tiles where the picture
> does not reflect the full connectivity function of that hex/tile.
> Examples:
> - PRR and Reading bases in the 1830 Coalfields and Reading variants,
> - Most off-map hexes, and specifically the 1856 Goderich and 18EU Hamburg:
> there is an undisplayed city on these hexes, that in the two cases mentioned
> can even be run through.
> - the sticky version of the brown plain track tiles in some games, like 18EU.
> In these cases the connectivity specification (in Tiles.xml) and the SVG
> picture are different, so the latter is unusable to base route calculations
> upon.
> 
> Erik.
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] batik and svg documents (was: Background Maps)

[Adam B. <ab...@o2...>]

And to fully benefit from the SVG model it would be great if the tile 
description had some mapping to SVG image of the tile. If for example 
station entry had an argument "svg-id" which would name identifier of SVG 
tile element which represents the station. Then the SVG map document code 
would not have to care that much about actual details of how the SVG makes 
the station (is it a single circle with border? or are those two circles of 
different radius wrapped in a an svg:g container? or whatever else...). It 
would know that it has to look for ID element and either replace it with 
station token element or to lay the station token element on the same 
position or whatever it likes. Yet it would be much easier.

Another example is marking routes. If a route from edge X to edge Y would be 
realized by ID1, ID2, ... IDn elements in SVG the code could just change 
style of those elements (for example change color to Train 1 color) and 
expect the route to be marked well.

If user clicks a station mark on SVG tile map manager will know ID of the 
"conceptual element" that was clicked and could easily in effect determine 
(based on the tile description) what was it. It easily transforms clicking 
"this white cirlce" into clicking NW station on a double station tile...

-----Oryginalna wiadomość----- 
From: Erik Vos
Sent: Thursday, August 18, 2011 11:39 AM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)

> -----Original Message-----
> From: Adam Badura [mailto:ab...@o2...]
> Sent: Thursday, August 18, 2011 12:20 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
>
> With SVG+XML I meant that (in my opinion) SVG should be used purly for
> presentation. Tile "description" (like number of stations, track 
> connections
> between hex edges, stations on that tracks, and so on...) should be stored
> separately (so not to mix different tile aspects). This also allows to 
> easly use
> different tile "styles" without need to change code that analyzes runs or
> finds possible tile lays.

I fully agree with that.  Several games have hexes and tiles where the 
picture does not reflect the full connectivity function of that hex/tile.
Examples:
- PRR and Reading bases in the 1830 Coalfields and Reading variants,
- Most off-map hexes, and specifically the 1856 Goderich and 18EU Hamburg: 
there is an undisplayed city on these hexes, that in the two cases mentioned 
can even be run through.
- the sticky version of the brown plain track tiles in some games, like 
18EU.
In these cases the connectivity specification (in Tiles.xml) and the SVG 
picture are different, so the latter is unusable to base route calculations 
upon.

Erik.


------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

There is another SVG related open issue with the 18EU SVG map that has been added a while ago. 
It looks nice, but on zooming in and out repeatedly, the scales of the map and the laid tiles start running out of sync.  I was not able to fix that.

Erik.

> -----Original Message-----
> From: Adam Badura [mailto:ab...@o2...]
> Sent: Thursday, August 18, 2011 1:06 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
> 
> On attachement patch for SVG document to be applied at current revision.
> With code modified that way load an existing game and enjoy the board
> (now I only checked 18AL, but others should work to).
> 
> Batik provides internal manipulators. While holding Ctrl use left and right
> mouse buttons to rotate or zoom for example (see how on large zooms the
> tiles still fit well).
> 
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Wednesday, August 17, 2011 11:52 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
> 
> Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML.
> 
> Personally, I'd like to see Rails simply make use of the information contained
> within the SVG rather than duplicate the exact same information in some
> other alternative format that's also XML. However, that would require
> leveraging Batik more extensively, not less.
> 
> I think I wrote most of the Swing and drawing code. It's crap. ;-) This is
> because I was learning my way around Swing while writing it. I definitely
> would like to see it refactored and improved upon.
> 
> Adam - can you post your patches to show your ideas?  It sounds like there's
> some interest in at least seeing how far you got with your ideas.
> 
> ---Brett.
> 
> 
> 
> On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote:
> > In general I do like thinking that I'm working on it. Yet in reality I
> > haven't done anything for a long time now. Mostly due to now 2
> > children consuming way to much time. ;) (And this requires serious
> > investigations into Java, SVG and Rails itself thus I have to be
> > rather focused and fresh to work on it...)
> >
> > I would not mind anyone taking over the patch especially that I cannot
> > promise when I will do it myself. I could serve with advice or
> > reviewing if that was desired.
> >
> >
> > The patch itself showed only how the map looks like when drawn by
> > providing SVG document. It was far from usable. (No selection, no
> > proper scrolling, no stations, ...)
> >
> >
> > I chose generating SVG document (as XML DOM) based on map and
> current
> > state (as opposed to drawing through Batik) because:
> > (1) I think it adds a reasonable layer of abstraction. It is much
> > easier to write (and then maintain) code that generates XML then code
> > that draws.
> > (2) I think it is more reusable generally. Such document could be
> > saved and used outside of Rails.
> > (3) I simply like XML. And that was part of my investigations in
> > maintining a better XML+SVG tiles repository for 18xx.
> >
> > -----Oryginalna wiadomość-----
> > From: Stefan Frey
> > Sent: Wednesday, August 17, 2011 10:43 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] batik and svg documents (was: Background
> > Maps)
> >
> > Adam & Erik,
> > going back through the archives of mails, which I did not read
> > carefully before, I saw this patch.
> >
> > What happened to it, it seems that it was not applied to the trunk,
> > but maybe it went into a svn branch and was not imported into git?
> >
> > I did not look into the display code too much (only a few fixes until
> > now and the train paths), however even at that time I was surprised
> > that the existing code mainly used standard awt/swing functions
> > instead of the batik svg functionality.
> >
> > The approach of Adam to create a SVG document directly is one way.
> > Another possibility is to create the SVG document indirectly by
> > replacing the Graphics2D implementation with the batik provided
> SVGGraphics2D engine.
> >
> > This redirects the Java graphics functions to store the output as SVG
> > elements into the SVG document.
> >
> > So questions are: Adam are you still working on this? And what was the
> > reason for you Erik to not following up this direction (most likely
> > many other
> > to-
> > dos)?
> >
> > I imagine that creating a unified SVG document would make the adding
> > alternative GUIs much easier than now.
> >
> > Stefan
> >
> >
> >
> > On Monday, June 06, 2011 11:45:57 pm Adam Badura 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
> >
> >
> > ----------------------------------------------------------------------
> > -------- Get a FREE DOWNLOAD! and learn more about uberSVN rich
> > system, user administration capabilities and model configuration. Take
> > the hassle out of deploying and managing Subversion and the tools
> > developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- Get a FREE DOWNLOAD! and learn more about uberSVN rich
> > system, user administration capabilities and model configuration. Take
> > the hassle out of deploying and managing Subversion and the tools
> > developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

> -----Original Message-----
> From: Adam Badura [mailto:ab...@o2...]
> Sent: Thursday, August 18, 2011 12:20 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
> 
> With SVG+XML I meant that (in my opinion) SVG should be used purly for
> presentation. Tile "description" (like number of stations, track connections
> between hex edges, stations on that tracks, and so on...) should be stored
> separately (so not to mix different tile aspects). This also allows to easly use
> different tile "styles" without need to change code that analyzes runs or
> finds possible tile lays.

I fully agree with that.  Several games have hexes and tiles where the picture does not reflect the full connectivity function of that hex/tile.
Examples:
- PRR and Reading bases in the 1830 Coalfields and Reading variants,
- Most off-map hexes, and specifically the 1856 Goderich and 18EU Hamburg: there is an undisplayed city on these hexes, that in the two cases mentioned can even be run through.
- the sticky version of the brown plain track tiles in some games, like 18EU.
In these cases the connectivity specification (in Tiles.xml) and the SVG picture are different, so the latter is unusable to base route calculations upon.

Erik.

Re: [Rails-devel] batik and svg documents (was: Background Maps)

[Adam B. <ab...@o2...>]

On attachement patch for SVG document to be applied at current revision. 
With code modified that way load an existing game and enjoy the board (now I 
only checked 18AL, but others should work to).

Batik provides internal manipulators. While holding Ctrl use left and right 
mouse buttons to rotate or zoom for example (see how on large zooms the 
tiles still fit well).

-----Oryginalna wiadomość----- 
From: brett lentz
Sent: Wednesday, August 17, 2011 11:52 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)

Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML.

Personally, I'd like to see Rails simply make use of the information
contained within the SVG rather than duplicate the exact same
information in some other alternative format that's also XML. However,
that would require leveraging Batik more extensively, not less.

I think I wrote most of the Swing and drawing code. It's crap. ;-)
This is because I was learning my way around Swing while writing it. I
definitely would like to see it refactored and improved upon.

Adam - can you post your patches to show your ideas?  It sounds like
there's some interest in at least seeing how far you got with your
ideas.

---Brett.



On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote:
> In general I do like thinking that I'm working on it. Yet in reality I
> haven't done anything for a long time now. Mostly due to now 2 children
> consuming way to much time. ;) (And this requires serious investigations
> into Java, SVG and Rails itself thus I have to be rather focused and fresh
> to work on it...)
>
> I would not mind anyone taking over the patch especially that I cannot
> promise when I will do it myself. I could serve with advice or reviewing 
> if
> that was desired.
>
>
> The patch itself showed only how the map looks like when drawn by 
> providing
> SVG document. It was far from usable. (No selection, no proper scrolling, 
> no
> stations, ...)
>
>
> I chose generating SVG document (as XML DOM) based on map and current 
> state
> (as opposed to drawing through Batik) because:
> (1) I think it adds a reasonable layer of abstraction. It is much easier 
> to
> write (and then maintain) code that generates XML then code that draws.
> (2) I think it is more reusable generally. Such document could be saved 
> and
> used outside of Rails.
> (3) I simply like XML. And that was part of my investigations in 
> maintining
> a better XML+SVG tiles repository for 18xx.
>
> -----Oryginalna wiadomość-----
> From: Stefan Frey
> Sent: Wednesday, August 17, 2011 10:43 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
>
> Adam & Erik,
> going back through the archives of mails, which I did not read carefully
> before, I saw this patch.
>
> What happened to it, it seems that it was not applied to the trunk, but
> maybe
> it went into a svn branch and was not imported into git?
>
> I did not look into the display code too much (only a few fixes until now
> and
> the train paths), however even at that time I was surprised that the
> existing
> code mainly used standard awt/swing functions instead of the batik svg
> functionality.
>
> The approach of Adam to create a SVG document directly is one way. Another
> possibility is to create the SVG document indirectly by replacing the
> Graphics2D implementation with the batik provided SVGGraphics2D engine.
>
> This redirects the Java graphics functions to store the output as SVG
> elements
> into the SVG document.
>
> So questions are: Adam are you still working on this? And what was the
> reason
> for you Erik to not following up this direction (most likely many other 
> to-
> dos)?
>
> I imagine that creating a unified SVG document would make the adding
> alternative GUIs much easier than now.
>
> Stefan
>
>
>
> On Monday, June 06, 2011 11:45:57 pm Adam Badura 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
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] batik and svg documents (was: Background Maps)

[Adam B. <ab...@o2...>]

With SVG+XML I meant that (in my opinion) SVG should be used purly for 
presentation. Tile "description" (like number of stations, track connections 
between hex edges, stations on that tracks, and so on...) should be stored 
separately (so not to mix different tile aspects). This also allows to easly 
use different tile "styles" without need to change code that analyzes runs 
or finds possible tile lays.

As to providing patch with demo of what I am trying to do I will do my best. 
The patch previously sent by me can no longer be easly applied do to code 
changes. I will try to produce a new one ASAP. Yet there is not much to look 
at. Instead of manual drawing I generate SVG document of the map and tiles 
on it and then set it to Batik Swing component. Batik deals with drawing on 
its own.

-----Oryginalna wiadomość----- 
From: Erik Vos
Sent: Thursday, August 18, 2011 12:12 AM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)

> Not to pick nits needlessly, but SVG *is* XML. The whole file format is 
> XML.

SVG is XML inasmuch Rails is Java.  Knowing a language does not necessarily 
make you understand any content written in that language.


------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

> Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML.

SVG is XML inasmuch Rails is Java.  Knowing a language does not necessarily make you understand any content written in that language.

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML.

Personally, I'd like to see Rails simply make use of the information
contained within the SVG rather than duplicate the exact same
information in some other alternative format that's also XML. However,
that would require leveraging Batik more extensively, not less.

I think I wrote most of the Swing and drawing code. It's crap. ;-)
This is because I was learning my way around Swing while writing it. I
definitely would like to see it refactored and improved upon.

Adam - can you post your patches to show your ideas?  It sounds like
there's some interest in at least seeing how far you got with your
ideas.

---Brett.



On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote:
> In general I do like thinking that I'm working on it. Yet in reality I
> haven't done anything for a long time now. Mostly due to now 2 children
> consuming way to much time. ;) (And this requires serious investigations
> into Java, SVG and Rails itself thus I have to be rather focused and fresh
> to work on it...)
>
> I would not mind anyone taking over the patch especially that I cannot
> promise when I will do it myself. I could serve with advice or reviewing if
> that was desired.
>
>
> The patch itself showed only how the map looks like when drawn by providing
> SVG document. It was far from usable. (No selection, no proper scrolling, no
> stations, ...)
>
>
> I chose generating SVG document (as XML DOM) based on map and current state
> (as opposed to drawing through Batik) because:
> (1) I think it adds a reasonable layer of abstraction. It is much easier to
> write (and then maintain) code that generates XML then code that draws.
> (2) I think it is more reusable generally. Such document could be saved and
> used outside of Rails.
> (3) I simply like XML. And that was part of my investigations in maintining
> a better XML+SVG tiles repository for 18xx.
>
> -----Oryginalna wiadomość-----
> From: Stefan Frey
> Sent: Wednesday, August 17, 2011 10:43 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)
>
> Adam & Erik,
> going back through the archives of mails, which I did not read carefully
> before, I saw this patch.
>
> What happened to it, it seems that it was not applied to the trunk, but
> maybe
> it went into a svn branch and was not imported into git?
>
> I did not look into the display code too much (only a few fixes until now
> and
> the train paths), however even at that time I was surprised that the
> existing
> code mainly used standard awt/swing functions instead of the batik svg
> functionality.
>
> The approach of Adam to create a SVG document directly is one way. Another
> possibility is to create the SVG document indirectly by replacing the
> Graphics2D implementation with the batik provided SVGGraphics2D engine.
>
> This redirects the Java graphics functions to store the output as SVG
> elements
> into the SVG document.
>
> So questions are: Adam are you still working on this? And what was the
> reason
> for you Erik to not following up this direction (most likely many other to-
> dos)?
>
> I imagine that creating a unified SVG document would make the adding
> alternative GUIs much easier than now.
>
> Stefan
>
>
>
> On Monday, June 06, 2011 11:45:57 pm Adam Badura 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
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

> And what was the
> reason for you Erik to not following up this direction (most likely many other
> to- dos)?

I have never been seriously involved in any graphics programming. I just understand Swing to some extent, but please don't ask any deep questions.

Nevertheless Adam had succeeded in raising some interest with me about SVG programming, so I tried to find some usable introductory documentation on how to use Batik. But I couldn't find anything.  So I quit.

Erik. 
 

Re: [Rails-devel] batik and svg documents (was: Background Maps)

[Adam B. <ab...@o2...>]

In general I do like thinking that I'm working on it. Yet in reality I 
haven't done anything for a long time now. Mostly due to now 2 children 
consuming way to much time. ;) (And this requires serious investigations 
into Java, SVG and Rails itself thus I have to be rather focused and fresh 
to work on it...)

I would not mind anyone taking over the patch especially that I cannot 
promise when I will do it myself. I could serve with advice or reviewing if 
that was desired.


The patch itself showed only how the map looks like when drawn by providing 
SVG document. It was far from usable. (No selection, no proper scrolling, no 
stations, ...)


I chose generating SVG document (as XML DOM) based on map and current state 
(as opposed to drawing through Batik) because:
(1) I think it adds a reasonable layer of abstraction. It is much easier to 
write (and then maintain) code that generates XML then code that draws.
(2) I think it is more reusable generally. Such document could be saved and 
used outside of Rails.
(3) I simply like XML. And that was part of my investigations in maintining 
a better XML+SVG tiles repository for 18xx.

-----Oryginalna wiadomość----- 
From: Stefan Frey
Sent: Wednesday, August 17, 2011 10:43 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps)

Adam & Erik,
going back through the archives of mails, which I did not read carefully
before, I saw this patch.

What happened to it, it seems that it was not applied to the trunk, but 
maybe
it went into a svn branch and was not imported into git?

I did not look into the display code too much (only a few fixes until now 
and
the train paths), however even at that time I was surprised that the 
existing
code mainly used standard awt/swing functions instead of the batik svg
functionality.

The approach of Adam to create a SVG document directly is one way. Another
possibility is to create the SVG document indirectly by replacing the
Graphics2D implementation with the batik provided SVGGraphics2D engine.

This redirects the Java graphics functions to store the output as SVG 
elements
into the SVG document.

So questions are: Adam are you still working on this? And what was the 
reason
for you Erik to not following up this direction (most likely many other to-
dos)?

I imagine that creating a unified SVG document would make the adding
alternative GUIs much easier than now.

Stefan



On Monday, June 06, 2011 11:45:57 pm Adam Badura 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


------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel 

Re: [Rails-devel] batik and svg documents (was: Background Maps)

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

Adam & Erik,
going back through the archives of mails, which I did not read carefully 
before, I saw this patch.

What happened to it, it seems that it was not applied to the trunk, but maybe 
it went into a svn branch and was not imported into git?

I did not look into the display code too much (only a few fixes until now and 
the train paths), however even at that time I was surprised that the existing 
code mainly used standard awt/swing functions instead of the batik svg 
functionality. 

The approach of Adam to create a SVG document directly is one way. Another 
possibility is to create the SVG document indirectly by replacing the 
Graphics2D implementation with the batik provided SVGGraphics2D engine.

This redirects the Java graphics functions to store the output as SVG elements 
into the SVG document.

So questions are: Adam are you still working on this? And what was the reason 
for you Erik to not following up this direction (most likely many other to-
dos)?

I imagine that creating a unified SVG document would make the adding 
alternative GUIs much easier than now.

Stefan



On Monday, June 06, 2011 11:45:57 pm Adam Badura 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

Re: [Rails-devel] Stop properties (1c25df)

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

I would like the revenue display to show city name, coordinates and value,
e.g. Boston F14 (30).  If only one can be displayed, city name and value are
preferred, e.g. Boston (30).

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Aug 16, 2011 at 10:34 PM, Stefan Frey <ste...@we...> wrote:

> All functions are used now.
> The off-map areas decision should be done after the release.
>
> However getName() would still be required if anyone prefers that the
> revenue
> display shows city names instead of the hex coordinates.
>
> Any opinion of this from the users?
>
> Stefan
>
>
> On Tuesday, August 16, 2011 09:54:14 pm Erik Vos wrote:
> > I have added the following three methods to Stop:
> >
> > runThroughAllowedFor(company),
> > runToAllowedFor(company),
> > getValueForPhase (phase).
> >
> > These methods aren't used yet.
> > I'm leaving getName() out for now, pending the discussion on looping and
> > off-map areas.  Neither did I change method visibilities yet.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Erik Vos [mailto:eri...@xs...]
> > > Sent: Monday, August 15, 2011 9:29 PM
> > > To: 'Development list for Rails: an 18xx game'
> > > Subject: Re: [Rails-devel] Stop properties
> > >
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > Sent: Monday, August 15, 2011 6:25 PM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Stop properties
> > > >
> > > > Erik:
> > > > I tried to change my coding in NetworkVertex accordingly.
> > > > Thanks a lot this will simplify the previous code needed to adapt the
> > >
> > > revenue
> > >
> > > > code to the algorithm code substantially.
> > > >
> > > > However as usual with coding one realizes some more thing.
> > > >
> > > > I think having those attributes are one thing, checking if runThrough
> > > > or
> > >
> > > runTo
> > >
> > > > is possible still requires more than that.
> > > >
> > > > The best solution would be adding additional methods for if a
> > > > runThrough and a runTo is possible for a specific company. Thus it
> > > > also checks the
> > >
> > > current
> > >
> > > > token situation.
> > > >
> > > > Thus something like
> > > >
> > > > public boolean runThroughAllowedFor(PublicCompanyI company) public
> > > > boolean runToAllowedFor(PublicCompanyI company)
> > >
> > > Hmm, that does make sense.
> > >
> > > > >From my perspective you could then define the
> > > >
> > > > isRunToAllowed/isRunThroughAllowed for  as private or even remove it,
> > > > as this is only required internally. Similar for the according
> methods
> > > > in
> > >
> > > MapHex
> > >
> > > > or Tile, they only need to be package private and not public.
> > >
> > > On the supposition that we will never subclass MapHex, Stop and Tile.
> But
> > > that's indeed unlikely.
> > >
> > > > Even better would be if  you could add similar methods. Then all
> > > > values
> > >
> > > are
> > >
> > > > retrieved from the stop object, instead of sometimes querying hex or
> > >
> > > station
> > >
> > > > instead.
> > > >
> > > > * public int getValueAt(PhaseI phase)
> > > > Retrieves the current value (either from the related station for
> > >
> > > cities/towns
> > >
> > > > or via the MapHex for offboard defined values)
> > > >
> > > > * public String getName()
> > > > Retrieves the name: Either from the hex or if undefined there from
> the
> > > > related station.
> > > >
> > > > Again this would allow to restrict access/visibility of a lot of
> > > > related
> > >
> > > methods
> > >
> > > > in Stop / Station / MapHex.
> > >
> > > I think getName() must be public everywhere - it's used in many ways.
> > >
> > > Ok, this all should be doable, hopefully before I'm going on vacation
> > > next week Wednesday for almost three weeks.  During my vacation you
> > > probably won't hear from me.
> > >
> > > Erik.
> >
> >
> ---------------------------------------------------------------------------
> > - --
> >
> > > uberSVN's rich system and user administration capabilities and model
> > > configuration take the hassle out of deploying and managing Subversion
> > > and the tools developers use with it. Learn more about uberSVN and get
> a
> > > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> ---------------------------------------------------------------------------
> > --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> > user administration capabilities and model configuration. Take
> > the hassle out of deploying and managing Subversion and the
> > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Stop properties (1c25df)

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

On Wed, Aug 17, 2011 at 3:39 AM, Phil Davies <de...@gm...> wrote:

> By revenue display do you mean the calculation that appears at the top
> of the screen during a run calc?  I'm happy for that to be hex coords
> personally since the graph line gives you a better understanding of
> where it's going.  I'd always want the mouseover text for hexes to
> have the city name and the hex coords


I agree.

Re: [Rails-devel] Patch: 1830 Reading upgrade for tile 15

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

Thanks, Bill.
I have applied this fix.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Wednesday, August 17, 2011 10:12 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Patch: 1830 Reading upgrade for tile 15
> 
> Hello,
> 
> As currently implemented in Rails, tile 15 cannot be upgraded in 1830
> Reading.  I can find no mention of this in the rules for this variant --
it looks
> like 'Reading' was omitted from the variants list here too.  The patch
below
> adds it back in.
> 
> My apologies for not catching and fixing this in the previous patch.  I've
> looked through the rest of the 1830 XML files and I don't see anywhere
else
> that the Reading variant is missing.
> 
> Bill

Re: [Rails-devel] Stop properties (1c25df)

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

By revenue display do you mean the calculation that appears at the top
of the screen during a run calc?  I'm happy for that to be hex coords
personally since the graph line gives you a better understanding of
where it's going.  I'd always want the mouseover text for hexes to
have the city name and the hex coords

On 17 August 2011 06:34, Stefan Frey <ste...@we...> wrote:
> All functions are used now.
> The off-map areas decision should be done after the release.
>
> However getName() would still be required if anyone prefers that the revenue
> display shows city names instead of the hex coordinates.
>
> Any opinion of this from the users?
>
> Stefan
>
>
> On Tuesday, August 16, 2011 09:54:14 pm Erik Vos wrote:
>> I have added the following three methods to Stop:
>>
>> runThroughAllowedFor(company),
>> runToAllowedFor(company),
>> getValueForPhase (phase).
>>
>> These methods aren't used yet.
>> I'm leaving getName() out for now, pending the discussion on looping and
>> off-map areas.  Neither did I change method visibilities yet.
>>
>> Erik.
>>
>> > -----Original Message-----
>> > From: Erik Vos [mailto:eri...@xs...]
>> > Sent: Monday, August 15, 2011 9:29 PM
>> > To: 'Development list for Rails: an 18xx game'
>> > Subject: Re: [Rails-devel] Stop properties
>> >
>> > > -----Original Message-----
>> > > From: Stefan Frey [mailto:ste...@we...]
>> > > Sent: Monday, August 15, 2011 6:25 PM
>> > > To: Development list for Rails: an 18xx game
>> > > Subject: Re: [Rails-devel] Stop properties
>> > >
>> > > Erik:
>> > > I tried to change my coding in NetworkVertex accordingly.
>> > > Thanks a lot this will simplify the previous code needed to adapt the
>> >
>> > revenue
>> >
>> > > code to the algorithm code substantially.
>> > >
>> > > However as usual with coding one realizes some more thing.
>> > >
>> > > I think having those attributes are one thing, checking if runThrough
>> > > or
>> >
>> > runTo
>> >
>> > > is possible still requires more than that.
>> > >
>> > > The best solution would be adding additional methods for if a
>> > > runThrough and a runTo is possible for a specific company. Thus it
>> > > also checks the
>> >
>> > current
>> >
>> > > token situation.
>> > >
>> > > Thus something like
>> > >
>> > > public boolean runThroughAllowedFor(PublicCompanyI company) public
>> > > boolean runToAllowedFor(PublicCompanyI company)
>> >
>> > Hmm, that does make sense.
>> >
>> > > >From my perspective you could then define the
>> > >
>> > > isRunToAllowed/isRunThroughAllowed for  as private or even remove it,
>> > > as this is only required internally. Similar for the according methods
>> > > in
>> >
>> > MapHex
>> >
>> > > or Tile, they only need to be package private and not public.
>> >
>> > On the supposition that we will never subclass MapHex, Stop and Tile. But
>> > that's indeed unlikely.
>> >
>> > > Even better would be if  you could add similar methods. Then all
>> > > values
>> >
>> > are
>> >
>> > > retrieved from the stop object, instead of sometimes querying hex or
>> >
>> > station
>> >
>> > > instead.
>> > >
>> > > * public int getValueAt(PhaseI phase)
>> > > Retrieves the current value (either from the related station for
>> >
>> > cities/towns
>> >
>> > > or via the MapHex for offboard defined values)
>> > >
>> > > * public String getName()
>> > > Retrieves the name: Either from the hex or if undefined there from the
>> > > related station.
>> > >
>> > > Again this would allow to restrict access/visibility of a lot of
>> > > related
>> >
>> > methods
>> >
>> > > in Stop / Station / MapHex.
>> >
>> > I think getName() must be public everywhere - it's used in many ways.
>> >
>> > Ok, this all should be doable, hopefully before I'm going on vacation
>> > next week Wednesday for almost three weeks.  During my vacation you
>> > probably won't hear from me.
>> >
>> > Erik.
>>
>> ---------------------------------------------------------------------------
>> - --
>>
>> > uberSVN's rich system and user administration capabilities and model
>> > configuration take the hassle out of deploying and managing Subversion
>> > and the tools developers use with it. Learn more about uberSVN and get a
>> > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Patch: 1830 Reading upgrade for tile 15

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

Hello,

As currently implemented in Rails, tile 15 cannot be upgraded in 1830 Reading.  I can find no mention of this in the rules for this variant -- it looks like 'Reading' was omitted from the variants list here too.  The patch below adds it back in.

My apologies for not catching and fixing this in the previous patch.  I've looked through the rest of the 1830 XML files and I don't see anywhere else that the Reading variant is missing.

Bill

Re: [Rails-devel] Release Planning

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

Perfect,
I have nothing to commit now, all tests are running.
Due to the new patch a new game with options can be started.

I only realized that there is an option for a 1830 Reading that is not defined 
in LocalisedText.

Stefan

On Tuesday, August 16, 2011 10:24:46 pm brett lentz wrote:
> I'm fine with doing a release. I'll make the new version tag on
> Friday, or as soon as Erik and Stefan confirm a desired tag point.
> 
> ---Brett.
> 
> On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...> wrote:
> > Brett & Erik,
> > maybe a new release should be done this weekend to have all the new games
> > out for testing during Erik's vacation?
> > Stefan
> > 
> >> Ok, this all should be doable, hopefully before I'm going on vacation
> >> next week Wednesday for almost three weeks.  During my vacation you
> >> probably won't hear from me.
> >> 
> >> Erik.
> >> 
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- uberSVN's rich system and user administration capabilities and
> >> model configuration take the hassle out of deploying and managing
> >> Subversion and the tools developers use with it. Learn more about
> >> uberSVN and get a free download at:
> >>  http://p.sf.net/sfu/wandisco-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- uberSVN's rich system and user administration capabilities and
> > model configuration take the hassle out of deploying and managing
> > Subversion and the tools developers use with it. Learn more about
> > uberSVN and get a free download at:
> >  http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties (1c25df)

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

All functions are used now.
The off-map areas decision should be done after the release.

However getName() would still be required if anyone prefers that the revenue 
display shows city names instead of the hex coordinates.

Any opinion of this from the users?

Stefan


On Tuesday, August 16, 2011 09:54:14 pm Erik Vos wrote:
> I have added the following three methods to Stop:
> 
> runThroughAllowedFor(company),
> runToAllowedFor(company),
> getValueForPhase (phase).
> 
> These methods aren't used yet.
> I'm leaving getName() out for now, pending the discussion on looping and
> off-map areas.  Neither did I change method visibilities yet.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Monday, August 15, 2011 9:29 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Stop properties
> > 
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Monday, August 15, 2011 6:25 PM
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Stop properties
> > > 
> > > Erik:
> > > I tried to change my coding in NetworkVertex accordingly.
> > > Thanks a lot this will simplify the previous code needed to adapt the
> > 
> > revenue
> > 
> > > code to the algorithm code substantially.
> > > 
> > > However as usual with coding one realizes some more thing.
> > > 
> > > I think having those attributes are one thing, checking if runThrough
> > > or
> > 
> > runTo
> > 
> > > is possible still requires more than that.
> > > 
> > > The best solution would be adding additional methods for if a
> > > runThrough and a runTo is possible for a specific company. Thus it
> > > also checks the
> > 
> > current
> > 
> > > token situation.
> > > 
> > > Thus something like
> > > 
> > > public boolean runThroughAllowedFor(PublicCompanyI company) public
> > > boolean runToAllowedFor(PublicCompanyI company)
> > 
> > Hmm, that does make sense.
> > 
> > > >From my perspective you could then define the
> > > 
> > > isRunToAllowed/isRunThroughAllowed for  as private or even remove it,
> > > as this is only required internally. Similar for the according methods
> > > in
> > 
> > MapHex
> > 
> > > or Tile, they only need to be package private and not public.
> > 
> > On the supposition that we will never subclass MapHex, Stop and Tile. But
> > that's indeed unlikely.
> > 
> > > Even better would be if  you could add similar methods. Then all
> > > values
> > 
> > are
> > 
> > > retrieved from the stop object, instead of sometimes querying hex or
> > 
> > station
> > 
> > > instead.
> > > 
> > > * public int getValueAt(PhaseI phase)
> > > Retrieves the current value (either from the related station for
> > 
> > cities/towns
> > 
> > > or via the MapHex for offboard defined values)
> > > 
> > > * public String getName()
> > > Retrieves the name: Either from the hex or if undefined there from the
> > > related station.
> > > 
> > > Again this would allow to restrict access/visibility of a lot of
> > > related
> > 
> > methods
> > 
> > > in Stop / Station / MapHex.
> > 
> > I think getName() must be public everywhere - it's used in many ways.
> > 
> > Ok, this all should be doable, hopefully before I'm going on vacation
> > next week Wednesday for almost three weeks.  During my vacation you
> > probably won't hear from me.
> > 
> > Erik.
> 
> ---------------------------------------------------------------------------
> - --
> 
> > uberSVN's rich system and user administration capabilities and model
> > configuration take the hassle out of deploying and managing Subversion
> > and the tools developers use with it. Learn more about uberSVN and get a
> > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits] rails/ui

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

Erik & Martin,
yes the sequence of rounds will be configurable.
StartRound and ShareRound are both PlayerRound(s). They differ by the allowed 
activities.

It will also be possible to assign strategies to control the ordering of 
acting entities (players or companies).

I expect it will be simpler to implement a game like 1880 in the new branch, 
however it will take some time to have at least something to work with. From 
my experience to implement revenue calculation, I believe 2-3 months are a 
realistic estimate.

Stefan


> 
> Here is a follow-up question for *Stefan Frey*:
> In your perceived Round.xml, do you plan to include XML to configure the
> StartRound/SR/OR sequence (1/2/3 ORs per SR, etc.)? That's an idea that
> Brett and I have discussed many years ago, but I never got to writing code
> for it.  If you do, it might become simple to declare two consecutive
> StartRounds, and Martin's problem would be easier to solve.
> 
> Otherwise, the simplest solution might be to create a 1880-specific version
> of StartRoundWindow to handle this issue (a changed player order in the
> middle of a round).
> 
> Erik.

Re: [Rails-devel] Stop properties

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

I'm fine.  
Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Tuesday, August 16, 2011 10:25 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Stop properties
> 
> I'm fine with doing a release. I'll make the new version tag on Friday, or as
> soon as Erik and Stefan confirm a desired tag point.
> 
> ---Brett.
> 
> 
> 
> On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...>
> wrote:
> > Brett & Erik,
> > maybe a new release should be done this weekend to have all the new
> > games out for testing during Erik's vacation?
> > Stefan
> >
> >
> >>
> >> Ok, this all should be doable, hopefully before I'm going on vacation
> >> next week Wednesday for almost three weeks.  During my vacation you
> >> probably won't hear from me.
> >>
> >> Erik.
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >> --- uberSVN's rich system and user administration capabilities and
> >> model configuration take the hassle out of deploying and managing
> >> Subversion and the tools developers use with it. Learn more about
> >> uberSVN and get a free download at:
> >> http://p.sf.net/sfu/wandisco-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -------- uberSVN's rich system and user administration capabilities
> > and model configuration take the hassle out of deploying and managing
> > Subversion and the tools developers use with it. Learn more about
> > uberSVN and get a free download at:
> > http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Stop properties

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

I'm fine with doing a release. I'll make the new version tag on
Friday, or as soon as Erik and Stefan confirm a desired tag point.

---Brett.



On Mon, Aug 15, 2011 at 10:12 PM, Stefan Frey <ste...@we...> wrote:
> Brett & Erik,
> maybe a new release should be done this weekend to have all the new games out
> for testing during Erik's vacation?
> Stefan
>
>
>>
>> Ok, this all should be doable, hopefully before I'm going on vacation next
>> week Wednesday for almost three weeks.  During my vacation you probably
>> won't hear from me.
>>
>> Erik.
>>
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Stop properties (be6c00)

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

I have added the following three methods to Stop:

runThroughAllowedFor(company),
runToAllowedFor(company),
getValueForPhase (phase).

These methods aren't used yet. 
I'm leaving getName() out for now, pending the discussion on looping and
off-map areas.  Neither did I change method visibilities yet.

Erik.


> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday, August 15, 2011 9:29 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Stop properties
> 
> 
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, August 15, 2011 6:25 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Stop properties
> >
> > Erik:
> > I tried to change my coding in NetworkVertex accordingly.
> > Thanks a lot this will simplify the previous code needed to adapt the
> revenue
> > code to the algorithm code substantially.
> >
> > However as usual with coding one realizes some more thing.
> >
> > I think having those attributes are one thing, checking if runThrough
> > or
> runTo
> > is possible still requires more than that.
> >
> > The best solution would be adding additional methods for if a
> > runThrough and a runTo is possible for a specific company. Thus it
> > also checks the
> current
> > token situation.
> >
> > Thus something like
> >
> > public boolean runThroughAllowedFor(PublicCompanyI company) public
> > boolean runToAllowedFor(PublicCompanyI company)
> 
> Hmm, that does make sense.
> 
> > >From my perspective you could then define the
> > isRunToAllowed/isRunThroughAllowed for  as private or even remove it,
> > as this is only required internally. Similar for the according methods
> > in
> MapHex
> > or Tile, they only need to be package private and not public.
> 
> On the supposition that we will never subclass MapHex, Stop and Tile. But
> that's indeed unlikely.
> 
> > Even better would be if  you could add similar methods. Then all
> > values
> are
> > retrieved from the stop object, instead of sometimes querying hex or
> station
> > instead.
> >
> > * public int getValueAt(PhaseI phase)
> > Retrieves the current value (either from the related station for
> cities/towns
> > or via the MapHex for offboard defined values)
> >
> > * public String getName()
> > Retrieves the name: Either from the hex or if undefined there from the
> > related station.
> >
> > Again this would allow to restrict access/visibility of a lot of
> > related
> methods
> > in Stop / Station / MapHex.
> 
> I think getName() must be public everywhere - it's used in many ways.
> 
> Ok, this all should be doable, hopefully before I'm going on vacation next
> week Wednesday for almost three weeks.  During my vacation you probably
> won't hear from me.
> 
> Erik.
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits] rails/ui

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

Hi Erik, 

	thanks for your reply and the thoughts you put into this. 

	One major problem cropped up though that i overlooked. 

	You cant reload (at least i couldnt) savefiles of 1880 after the
playerorientation had changed. This will need some effort i am afraid.


	StartroundWindow suffers also from a redirection, i will try to model
it after StatusWindow and find out if thats a viable approach to
handle differing player seatings. 

	[EV] The main question is: is it easier to make StartRoundWindow cope
 with a changed player order *in the middle of a round*, or splitting
the  round?  Perhaps the former, but I haven't yet been able to dig
into  that issue. 

	In the aspect of the save game problematic it might be easier to do
the latter, but again this is just a first impression/thought. 

	[EV] 1.  Does "it" (in this case: multiple start rounds) also occur
in other games? 

	Off hand:  1853, 18FL, 18US (Bidding or Contracting), Player Order
based on outcome, 1880

	Change of Player order in or after starting round: 1880, 1824,
1844(?), 1835 (CLemens Variant) 

	Maybe others i dont remember or havent played yet :) 

	StartRoundWindow_1880 might be the easiest way i agree, but for the
Savegame-Problematic. 

Regards, 

	Martin

	  Von: "Erik Vos" <eri...@xs...>
 An: <Dr....@t-...>, <ste...@we...>
 Cc: "Development list for Rails: an 18xx game"
<rai...@li...>
 Betreff: Re: [Rails-devel] [Rails-commits] rails/ui
 Datum: Tue, 16 Aug 2011 12:16:58 +0200

 See below (and there is also a question for Stefan Frey at the
bottom).

 >I have fixed current player highlighting in the StatusWindow. I have
not changed the player order (which I understand is what you >really
want), because that is not so easy to do.  I may work on that later.
 > 
 In the meantime i played around a bit on my own, the UI-Code is based
on some "static" behaviour regarding player ordering that might not be
true all the time.

 [EV] In the Game status window, the bits to handle changes player
ordering already existed (playerIndex, getCurrentPlayer() and
highlightCurrentPlayer()), but unfortunately I had forgotten to use
these...   
 I'm not sure to what extent StartRoundWindow is currently prepared
for different player orders.  Certainly it can (or could??) handle the
reverse bidding sequences in the  1835 Snake and Clemens Variants.

 >I also will look at the StartRoundWindow later. One aspect I want to
think about is if it’s right to sell the privates and the investors
>in the same StartRound, or that that round can better be split.
 > 
 Might be an Idea to have two Startpacket being handled consecutivly,
would need to check the code and of course rewrite the existing
behaviour once again :)(groan)

 [EV] The main question is: is it easier to make StartRoundWindow cope
with a changed player order *in the middle of a round*, or splitting
the round?  Perhaps the former, but I haven't yet been able to dig
into that issue.

 Two questions that always arise in such cases are:
 1.  Does "it" (in this case: multiple start rounds) also occur in
other games? 1844 is very complex, but not sure if we would need
multiple start rounds in that game.  Then we have 18US, where a second
"start round" occurs later in the game.  I don't think we need to look
at 1837 (however complex its start procedure is - it's much alike
1835). I'm not aware of other games where consecutive initial start
rounds could apply, but I haven't been closely following the newest
developments.
 2. If so, is it worthwhile to create generic code for it? Probably
not.

 Here is a follow-up question for *Stefan Frey*:
 In your perceived Round.xml, do you plan to include XML to configure
the StartRound/SR/OR sequence (1/2/3 ORs per SR, etc.)? That's an idea
that Brett and I have discussed many years ago, but I never got to
writing code for it.  If you do, it might become simple to declare two
consecutive StartRounds, and Martin's problem would be easier to
solve.

 Otherwise, the simplest solution might be to create a 1880-specific
version of StartRoundWindow to handle this issue (a changed player
order in the middle of a round).

 Erik.

 ------------------------------------------------------------------------------
 uberSVN's rich system and user administration capabilities and model 
 configuration take the hassle out of deploying and managing
Subversion and 
 the tools developers use with it. Learn more about uberSVN and get a
free 
 download at:  http://p.sf.net/sfu/wandisco-dev2dev
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] [Rails-commits] rails/ui

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

See below (and there is also a question for Stefan Frey at the bottom).

>I have fixed current player highlighting in the StatusWindow. I have not changed the player order (which I understand is what you >really want), because that is not so easy to do.  I may work on that later.
> 
In the meantime i played around a bit on my own, the UI-Code is based on some "static" behaviour regarding player ordering that might not be true all the time.

[EV] In the Game status window, the bits to handle changes player ordering already existed (playerIndex, getCurrentPlayer() and highlightCurrentPlayer()), but unfortunately I had forgotten to use these...   
I'm not sure to what extent StartRoundWindow is currently prepared for different player orders.  Certainly it can (or could??) handle the reverse bidding sequences in the  1835 Snake and Clemens Variants.

>I also will look at the StartRoundWindow later. One aspect I want to think about is if it’s right to sell the privates and the investors >in the same StartRound, or that that round can better be split.
> 
Might be an Idea to have two Startpacket being handled consecutivly, would need to check the code and of course rewrite the existing behaviour once again :)(groan)

[EV] The main question is: is it easier to make StartRoundWindow cope with a changed player order *in the middle of a round*, or splitting the round?  Perhaps the former, but I haven't yet been able to dig into that issue.

Two questions that always arise in such cases are:
1.  Does "it" (in this case: multiple start rounds) also occur in other games? 1844 is very complex, but not sure if we would need multiple start rounds in that game.  Then we have 18US, where a second "start round" occurs later in the game.  I don't think we need to look at 1837 (however complex its start procedure is - it's much alike 1835). I'm not aware of other games where consecutive initial start rounds could apply, but I haven't been closely following the newest developments.
2. If so, is it worthwhile to create generic code for it? Probably not.

Here is a follow-up question for *Stefan Frey*:
In your perceived Round.xml, do you plan to include XML to configure the StartRound/SR/OR sequence (1/2/3 ORs per SR, etc.)? That's an idea that Brett and I have discussed many years ago, but I never got to writing code for it.  If you do, it might become simple to declare two consecutive StartRounds, and Martin's problem would be easier to solve.

Otherwise, the simplest solution might be to create a 1880-specific version of StartRoundWindow to handle this issue (a changed player order in the middle of a round).

Erik.

Re: [Rails-devel] Stop properties

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

Stefan,

Thanks for reminding me on how you currently prevent loops by comparing
names - that had completely escaped my mind.
Now I also better understand your need for a Stop getName() method!
Indeed I was already concerned that my current "loop" idea cannot yet handle
the case of multiple-hex off-map areas.

> I am aware and support of other people adding games ;-) The two important
> words above are "simple" and/or "frequently".

Indeed.
 
> However quite often it seems that two games share the same mechanism
> (most of the time because they use the same terminology), but they are
> substantially different in mechanism: For example unfortunately it is not
> enough to add an attribute " merge='yes' " to companies to allow them
> merging...
> 
> So the 1860 example cannot be easily solved by adding the attributes. The
> short explanation is that currently all simple track that only connects
the
> scoring vertices are optimized away. It is possible to protect vertices
from
> that (for similar cases), however I do not like the idea to protect all
track
> vertices as it could be a drag on the revenue calculation, especially as
1860
> has some other rules to consider. So let us wait until we implement that
> game.

I agree.
 
> > We also have cases like 18EU Paris/Berlin/Vienna, where I already have
> > added loop="no". If you have no plan to start supporting it soon, my
> > hopeful loop settings should indeed be removed.
> 
> I forgot about that case: If only scoring vertices are meant this is
possible.
> Maybe we should call this scoreTwice = "no" as it avoids people from
thinking
> this is identical to loop (revisit twice).

Now I'm puzzled. I'm only aware of no-visit-twice cases (which obviously
implies no-score-twice).  Do really cases exist where revisit-twice is
allowed but score-twice is not?
Certainly not 1825 [rule 1.8] and the 18EU metropoles [rule 4.4.3, 6th
bullet point], which are definitely no-revisit cases. Also the routes to
determine 18EU minor connections may not revisit a tile.
Or do I now misunderstand you?
 
> This would replace the current identical name mechanism.

I vaguely remember having opposed to that mechanism before, but I can't find
back the emails about that.

> However we would still need a mechanism to prevent scoring multiple-hex
> offboard areas twice. I am not sure how you would like to implement that?
> 
> I think an off-board area attributes (name, values etc.) should be defined
> only once and then have a list of hexes it refers to.
> Then this object could be used directly to create the vertexVisitSet that
I
> currently have to create for the algorithm.
> But it makes the setup of the hexes harder, but I believe that is the
correct
> solution. 

I fully agree. And it wouldn't be that much harder.  For instance (1830):

<Area id="A9A11" name="Canadian West" value="30,50">
	<Access type="offmap"/>  - the offmap game defaults apply, including
loop="no".
</Area>
...
<Hex name="A9" area="A9A11" .../> - omitting value.

Perhaps we can somehow merge the stops of both tiles, or use one as the
primary stop for the area. 
In the latter case we could even omit the <Area> and have the second offmap
hex refer back to the first (which would be even easier to configure):

<Hex name="A9"/> - as it is now
<Hex name="A11" area="A9"/>  - which would make Hex A11 consider the A9
Station/Stop as its own in all respects, including value and access.

BTW I have long thought that in <Hex> we should rename 'name' to 'id' and
'city' to 'name', but it's probably not worthwhile taking that effort.

> I could volunteer to implement that.

If you like, otherwise I'll try.

Erik.