You can subscribe to this list here.
2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stefan F. <ste...@we...> - 2015-04-10 08:25:09
|
Second beta release for Rails 2.0 *** Improvements: - Company panel of OR window shows only acting company during tile, token and revenue steps. All companies shown at train buying. - Indicate for each player what company were already sold during share rounds. - Fixed information in message panel during tile/token lays. We are glad to receive feedback both on bugs and usability. There is a wiki on gitHub with rails 2.0 documentation: http://github.com/freystef/Rails/wiki *** Testing of Rails 2.0 beta 2 possible via Webstart or Download * Webstart the beta release: http://rails.sf.net/webstart/rails.jnlp * Download the beta release: Download the single jar and start it directly (by double-click or command line "java -jar" command). http://sourceforge.net/projects/rails/files/Rails/2.0/ |
From: Chris S. <chr...@gm...> - 2015-03-13 04:55:17
|
Many games allow sales in the first stock round, so this should be supported. On Thu, Mar 12, 2015 at 5:51 PM John David Galt < jd...@di...> wrote: > On 2015-03-12 13:56, Stefan Frey wrote: > > There seems to be a rule which is nearly identical for all 18xx: > > > > "There is no sale of company shares during the first round." > > See http://www.fwtwr.com/18xx/rules_difference_list/1_3.htm > > > > However what exactly is the definition of the first (share) round? > > I consider the definitive answer to be what it is in 1830: the first > stock round means everything that precedes the first operating round. > Thus the test for whether a player can sell shares should simply be > whether or not any company -- even a private -- has operated. > > (tl;dr The rest of this message is merely detail to support/explain this > theory.) > > Thus in 1830, the first stock round usually includes the entire set of > private-company auctions and goes on to cover the "regular stock round" > that follows those auctions. However, if all players pass at some > earlier point and private-company owners collect income, then the first > stock round has ended then. (If all players pass before the SVN&RR is > purchased, so that there is no operating round, the first stock round > has NOT ended and it continues to be illegal to sell any shares.) > > Similarly in 1835, the first stock round usually includes the sale of > the entire starting packet, and sometimes a small number of stock > purchases after it has sold out. But again it is possible for the first > stock round to end while some privates remain unsold -- in which case > under standard rules, an operating round takes place, thus ending the > first stock round. (I'm not sure exactly how the option setting "Minors > don't run if BY has not floated" affects this question. If that option > prevents even privates from paying out, then no operating round has > occurred, so the first stock round has NOT ended yet. But that's > academic, since if BY has not floated then the rule that you can't sell > any shares of companies which haven't operated (except PR) prevents you > from selling anything anyway.) > > Most games will follow one of these two general patterns, with some > variations. > > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: John D. G. <jd...@di...> - 2015-03-13 00:51:01
|
On 2015-03-12 13:56, Stefan Frey wrote: > There seems to be a rule which is nearly identical for all 18xx: > > "There is no sale of company shares during the first round." > See http://www.fwtwr.com/18xx/rules_difference_list/1_3.htm > > However what exactly is the definition of the first (share) round? I consider the definitive answer to be what it is in 1830: the first stock round means everything that precedes the first operating round. Thus the test for whether a player can sell shares should simply be whether or not any company -- even a private -- has operated. (tl;dr The rest of this message is merely detail to support/explain this theory.) Thus in 1830, the first stock round usually includes the entire set of private-company auctions and goes on to cover the "regular stock round" that follows those auctions. However, if all players pass at some earlier point and private-company owners collect income, then the first stock round has ended then. (If all players pass before the SVN&RR is purchased, so that there is no operating round, the first stock round has NOT ended and it continues to be illegal to sell any shares.) Similarly in 1835, the first stock round usually includes the sale of the entire starting packet, and sometimes a small number of stock purchases after it has sold out. But again it is possible for the first stock round to end while some privates remain unsold -- in which case under standard rules, an operating round takes place, thus ending the first stock round. (I'm not sure exactly how the option setting "Minors don't run if BY has not floated" affects this question. If that option prevents even privates from paying out, then no operating round has occurred, so the first stock round has NOT ended yet. But that's academic, since if BY has not floated then the rule that you can't sell any shares of companies which haven't operated (except PR) prevents you from selling anything anyway.) Most games will follow one of these two general patterns, with some variations. |
From: brett l. <bre...@gm...> - 2015-03-12 21:09:56
|
There's a third, slightly different option that some rule sets also use: C) You can't sell a share of a company that has not yet operated, even after the first Stock Round. IMO, B is _usually_ the correct behavior for most 1830-style games. In some, specific games, Rails should operate according to C, which will necessarily include A and often, but not always, includes B. So, Rails probably just needs a hasOperated boolean or lastORValue integer for every Company in order to implement C, and then we can tidy up which games need which behavior. ---Brett. ---Brett. On Thu, Mar 12, 2015 at 4:56 PM, Stefan Frey <ste...@we...> wrote: > There seems to be a rule which is nearly identical for all 18xx: > > "There is no sale of company shares during the first round." > See http://www.fwtwr.com/18xx/rules_difference_list/1_3.htm > > However what exactly is the definition of the first (share) round? > > In most 18xx the game starts with a kind of special distribution > (auction) of a packet of certificates. > > In Rails terminology this is the StartPacket and those rounds are called > StartRounds. > > There can be several StartRounds, if all player passes, a (short) > OperatingRound starts. In that round only private companies pay their > fixed dividend. > > After the StartPacket is fully sold, a StockRound immediately follows. > > Simple question: > The rule "no sale of shares during the first (share) round" is valid for > > A) Exactly the first round of the game, including that there the > StartPacket is on offer. If this round ends by all players passing, the > second (share) round begins, regardless if the StartPacket was sold or > not. From this point in the game shares can be sold (as soon as the > StartPacket is fully sold). > > B) The first StockRound that starts/continues immediately after the > StartPacket was sold. > > Or the more complex question: > Or might this be even game dependent? > > On a first glance into a few rules my guess is that it might be even the > latter (not surprisingly in 18xx). > > For 1830 and 1835 rules read as A) is correct. > > For 1856 and 1870 the rules seem to suggest B) as correct. > > The current Rails implementation for all games with that rule is B). > > Background: > > The cause for this mail is a off-list bug-report by Harald Stieling for > the 1835 implementation in Rails: > > 1835 allows to float a company (BY) even if the StartPacket is not fully > sold (e.g. the M4 or HB are unsold). > > So assume that BY floats in the first StartRound, operates once, then > Rails returns to selling the StartPacket in a second StartRound, > followed by the first StockRound. Now Rails assume that this is the > first share round, that no shares can be sold. This implies that no BY > shares can be sold, even if BY already operated. > This case is clearly against the rules of 1835. > > However to fix the bug, it would be great, if their is a general > consensus how to interpret the "no sale of shares in the first (share) > round" rule. At least for each 18xx implemented in Rails. ;-) > > More comments and views? > > Stefan > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Stefan F. <ste...@we...> - 2015-03-12 20:56:39
|
There seems to be a rule which is nearly identical for all 18xx: "There is no sale of company shares during the first round." See http://www.fwtwr.com/18xx/rules_difference_list/1_3.htm However what exactly is the definition of the first (share) round? In most 18xx the game starts with a kind of special distribution (auction) of a packet of certificates. In Rails terminology this is the StartPacket and those rounds are called StartRounds. There can be several StartRounds, if all player passes, a (short) OperatingRound starts. In that round only private companies pay their fixed dividend. After the StartPacket is fully sold, a StockRound immediately follows. Simple question: The rule "no sale of shares during the first (share) round" is valid for A) Exactly the first round of the game, including that there the StartPacket is on offer. If this round ends by all players passing, the second (share) round begins, regardless if the StartPacket was sold or not. From this point in the game shares can be sold (as soon as the StartPacket is fully sold). B) The first StockRound that starts/continues immediately after the StartPacket was sold. Or the more complex question: Or might this be even game dependent? On a first glance into a few rules my guess is that it might be even the latter (not surprisingly in 18xx). For 1830 and 1835 rules read as A) is correct. For 1856 and 1870 the rules seem to suggest B) as correct. The current Rails implementation for all games with that rule is B). Background: The cause for this mail is a off-list bug-report by Harald Stieling for the 1835 implementation in Rails: 1835 allows to float a company (BY) even if the StartPacket is not fully sold (e.g. the M4 or HB are unsold). So assume that BY floats in the first StartRound, operates once, then Rails returns to selling the StartPacket in a second StartRound, followed by the first StockRound. Now Rails assume that this is the first share round, that no shares can be sold. This implies that no BY shares can be sold, even if BY already operated. This case is clearly against the rules of 1835. However to fix the bug, it would be great, if their is a general consensus how to interpret the "no sale of shares in the first (share) round" rule. At least for each 18xx implemented in Rails. ;-) More comments and views? Stefan |
From: John D. G. <jd...@di...> - 2015-03-12 00:18:59
|
On 2015-03-11 17:12, com...@ip... wrote: > Rails is a competitive game as much as a cooperative one. Being able to see > stock values, revenues etc for rivals informs players as to the probable > strategies in place during the next stock round and how the corp currently > being operated should behave in the current round ie pay dividends, withhold, > etc. So I don't think this is a good idea. You're always able to see those things in the Game Status window. |
From: <com...@ip...> - 2015-03-12 00:12:15
|
Rails is a competitive game as much as a cooperative one. Being able to see stock values, revenues etc for rivals informs players as to the probable strategies in place during the next stock round and how the corp currently being operated should behave in the current round ie pay dividends, withhold, etc. So I don't think this is a good idea. Mike >-- Original Message -- >Date: Wed, 11 Mar 2015 19:30:48 +0100 >From: Stefan Frey <ste...@we...> >To: Development list for Rails: an 18xx game > <rai...@li...> >Subject: Re: [Rails-devel] Rails 2.0 discussion: Changes to OR Window? >Reply-To: "Development list for Rails: an 18xx game" > <rai...@li...> > > >John, Mike and Chris: >thanks for your suggestions. > >I will break all of your suggestions into tiny tidbits in my response to > >keep the discussion focused on each proposal. > >On 03/10/2015 10:39 PM, John David Galt wrote: > > And, dare I suggest: > > > > 3) Add "Privates", "Tiles", and "Tokens" columns to the Game Status > > window (and have the companies in that window move to reflect operating > > order each OR), thus eliminating any need to have a separate list of > > companies attached to the map window. This will make a HUGE difference > > on small screens, where I've been used to playing 18EU through a tiny > > "letter box" view of the map because the company-list part of the map > > pane won't allow itself to be shrunk!!! > > >In my view the huge panel of companies during the OR was distracting as >well. Unfortunately it is difficult to move fields given the current >code structure (this will improve in 2.1...). > >However what is possible in 2.1 is to change the visibility of companies > >during the OR. > >What about this: > >During tile/token/revenue steps: Show only one row with the current >operating company. > >During train buying step: Show all companies, as the map has no value >now and it is important to see where the trains currently are and what >is the operating order of companies. > >I already have a fix in the repo (branch rails_2_develop) that >implements this change. > >Stefan > > >------------------------------------------------------------------------------ >Dive into the World of Parallel Programming The Go Parallel Website, sponsored >by Intel and developed in partnership with Slashdot Media, is your hub for >all >things parallel software development, from weekly thought leadership blogs >to >news, videos, case studies, tutorials and more. Take a look and join the > >conversation now. http://goparallel.sourceforge.net/ >_______________________________________________ >Rails-devel mailing list >Rai...@li... >https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Chris S. <chr...@gm...> - 2015-03-11 20:44:45
|
It would be nice if there was a toggle during this phase. Sometimes the map is really important when buying trains. On Wed, Mar 11, 2015 at 11:31 AM Stefan Frey <ste...@we...> wrote: > John, Mike and Chris: > thanks for your suggestions. > > I will break all of your suggestions into tiny tidbits in my response to > keep the discussion focused on each proposal. > > On 03/10/2015 10:39 PM, John David Galt wrote: > > And, dare I suggest: > > > > 3) Add "Privates", "Tiles", and "Tokens" columns to the Game Status > > window (and have the companies in that window move to reflect operating > > order each OR), thus eliminating any need to have a separate list of > > companies attached to the map window. This will make a HUGE difference > > on small screens, where I've been used to playing 18EU through a tiny > > "letter box" view of the map because the company-list part of the map > > pane won't allow itself to be shrunk!!! > > > In my view the huge panel of companies during the OR was distracting as > well. Unfortunately it is difficult to move fields given the current > code structure (this will improve in 2.1...). > > However what is possible in 2.1 is to change the visibility of companies > during the OR. > > What about this: > > During tile/token/revenue steps: Show only one row with the current > operating company. > > During train buying step: Show all companies, as the map has no value > now and it is important to see where the trains currently are and what > is the operating order of companies. > > I already have a fix in the repo (branch rails_2_develop) that > implements this change. > > Stefan > > > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Stefan F. <ste...@we...> - 2015-03-11 18:31:04
|
John, Mike and Chris: thanks for your suggestions. I will break all of your suggestions into tiny tidbits in my response to keep the discussion focused on each proposal. On 03/10/2015 10:39 PM, John David Galt wrote: > And, dare I suggest: > > 3) Add "Privates", "Tiles", and "Tokens" columns to the Game Status > window (and have the companies in that window move to reflect operating > order each OR), thus eliminating any need to have a separate list of > companies attached to the map window. This will make a HUGE difference > on small screens, where I've been used to playing 18EU through a tiny > "letter box" view of the map because the company-list part of the map > pane won't allow itself to be shrunk!!! In my view the huge panel of companies during the OR was distracting as well. Unfortunately it is difficult to move fields given the current code structure (this will improve in 2.1...). However what is possible in 2.1 is to change the visibility of companies during the OR. What about this: During tile/token/revenue steps: Show only one row with the current operating company. During train buying step: Show all companies, as the map has no value now and it is important to see where the trains currently are and what is the operating order of companies. I already have a fix in the repo (branch rails_2_develop) that implements this change. Stefan |
From: John D. G. <jd...@di...> - 2015-03-10 22:05:20
|
On 2015-03-10 01:58, Stefan Frey wrote: > to get more feedback on the UI, I will try to make some more suggestions > how to improve the Rails 2.0 UI. I'll toss in my $.02 as well, whether you end up making any of the changes or not. I'll respond to your ideas first. > Those who tried the 2.0 beta already know that the buttons Confirm/Skip > have been move to the top of the upgrade panel and are always visible > (green circle in the attached image). > > First reason for that was to avoid scrolling down the upgrade panel to > finalize the tile lay. That in itself is not a bad change. However, I would want to make it a little "smarter" (in particular, if there's no legal tile lay or no legal token lay -- after considering both the supply of tiles (or tokens) and the company's treasury -- then skip that phase. In particular, 1835 should not be offering me the Pfalz tile lay unless (it's green phase AND that hex is unbuilt), and should not be offering me the Pfalz token lay unless (BA has placed its home token AND the hex still has an open city circle AND the operating company is not BA). While we're at it: 1) Make the top title bar of the map window SAY what it wants you to do during each step. (During both the tile-lay and token-lay steps in Rails 2.0-beta1, the title bar says only "Select a hex", which is completely unhelpful.) > I realized that now one has to use the buttons at the top of the upgrade > panel for tile/token laying, but the buttons at the bottom of the OR > window for later actions (payout, buy trains etc). > > My suggestion is to make UI easier is: > > A) Remove the button panel at the bottom of the OR window. OK, but then let's move all those buttons into that left side "upgrade" panel. It has the room, and it means we don't have to look more than one place during operating rounds. Also while we're at it, 2) Move the menu bar (where it shows "Info", "Special", and "Zoom" in your example image) from the bottom of the map to the very top, above the title bar. And, dare I suggest: 3) Add "Privates", "Tiles", and "Tokens" columns to the Game Status window (and have the companies in that window move to reflect operating order each OR), thus eliminating any need to have a separate list of companies attached to the map window. This will make a HUGE difference on small screens, where I've been used to playing 18EU through a tiny "letter box" view of the map because the company-list part of the map pane won't allow itself to be shrunk!!! > B) Move the undo/redo buttons to the bottom of the upgrade panel (always > visible) Agree. And keep each one in a fixed location. No more of the present situation where they move around horizontally during an OR. > C) Move the action buttons (payout/withhold/buy train) to the top of the > upgrade panel. This implies that the action buttons will change > depending on the activity. Agree, so long as this does not include Undo/Redo. > Open question is where to move "Buy Private". One possibility is to move > the buy Private button to a entry of the special menu? Or a separate > entry of the menu? Other ideas? "Buy Private" is one of several steps that happen so seldom that asking the player about them every turn can be an annoyance. I suggest we borrow an idea from another Sourceforge game project, Colossus, and create a large Options menu, changeable during a game, which allows the user to tell Rails to skip asking about certain actions. (Other actions my group would often want to skip being asked to do include: Pay back loans in 1856; buy or sell treasury stock in 1826 or 18EU; or take private-company actions in all games.) In all cases, the action so skipped should be available to players on the "Special" menu, so they're never deprived of the opportunity to do it if they remember. If they want to be asked they can turn that on. |
From: Chris S. <chr...@gm...> - 2015-03-10 15:21:02
|
Alternatively, have a "special actions" button that displays when special actions are possible, and have it open a menu of choices. On Tue, Mar 10, 2015 at 8:20 AM Chris Shaffer <chr...@gm...> wrote: > There are a number of special actions that can be executed at various > times, including taking special abilities granted by privates, like laying > a cattle token. I agree with Mike - make all of these, including buy > privates, individual buttons, only visible when available to the player to > take as an action. > > On Tue, Mar 10, 2015 at 3:31 AM <com...@ip...> wrote: > >> "buy privates" sounds like an action to me - why not group it with them, >> but have it only visible when relevant? >> >> Mike >> >> >> >-- Original Message -- >> >Date: Tue, 10 Mar 2015 09:58:58 +0100 >> >From: Stefan Frey <ste...@we...> >> >To: Development list for Rails: an 18xx game >> > <rai...@li...>, >> rai...@li... >> >Subject: [Rails-devel] Rails 2.0 discussion: Changes to OR Window? >> >Reply-To: "Development list for Rails: an 18xx game" >> > <rai...@li...> >> > >> > >> >Hi, >> >to get more feedback on the UI, I will try to make some more suggestions >> > >> >how to improve the Rails 2.0 UI. >> > >> >Those who tried the 2.0 beta already know that the buttons Confirm/Skip >> >> >have been move to the top of the upgrade panel and are always visible >> >(green circle in the attached image). >> > >> >First reason for that was to avoid scrolling down the upgrade panel to >> >finalize the tile lay. >> > >> >I realized that now one has to use the buttons at the top of the upgrade >> > >> >panel for tile/token laying, but the buttons at the bottom of the OR >> >window for later actions (payout, buy trains etc). >> > >> >My suggestion is to make UI easier is: >> > >> >A) Remove the button panel at the bottom of the OR window. >> > >> >B) Move the undo/redo buttons to the bottom of the upgrade panel (always >> > >> >visible) >> > >> >C) Move the action buttons (payout/withhold/buy train) to the top of the >> > >> >upgrade panel. This implies that the action buttons will change >> >depending on the activity. >> > >> >Open question is where to move "Buy Private". One possibility is to move >> > >> >the buy Private button to a entry of the special menu? Or a separate >> >entry of the menu? Other ideas? >> > >> >Feedback and other/further ideas are welcome. >> > >> >Stefan >> > >> >Attachment: UI_buttons_comments.png >> > >> >----------------------------------------------------------- >> ------------------- >> >Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> >by Intel and developed in partnership with Slashdot Media, is your hub >> for >> >all >> >things parallel software development, from weekly thought leadership >> blogs >> >to >> >news, videos, case studies, tutorials and more. Take a look and join the >> > >> >conversation now. http://goparallel.sourceforge.net/ >> >_______________________________________________ >> >Rails-devel mailing list >> >Rai...@li... >> >https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> ------------------------------------------------------------ >> ------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub >> for all >> things parallel software development, from weekly thought leadership >> blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > |
From: Chris S. <chr...@gm...> - 2015-03-10 15:20:36
|
There are a number of special actions that can be executed at various times, including taking special abilities granted by privates, like laying a cattle token. I agree with Mike - make all of these, including buy privates, individual buttons, only visible when available to the player to take as an action. On Tue, Mar 10, 2015 at 3:31 AM <com...@ip...> wrote: > "buy privates" sounds like an action to me - why not group it with them, > but have it only visible when relevant? > > Mike > > > >-- Original Message -- > >Date: Tue, 10 Mar 2015 09:58:58 +0100 > >From: Stefan Frey <ste...@we...> > >To: Development list for Rails: an 18xx game > > <rai...@li...>, > rai...@li... > >Subject: [Rails-devel] Rails 2.0 discussion: Changes to OR Window? > >Reply-To: "Development list for Rails: an 18xx game" > > <rai...@li...> > > > > > >Hi, > >to get more feedback on the UI, I will try to make some more suggestions > > > >how to improve the Rails 2.0 UI. > > > >Those who tried the 2.0 beta already know that the buttons Confirm/Skip > > >have been move to the top of the upgrade panel and are always visible > >(green circle in the attached image). > > > >First reason for that was to avoid scrolling down the upgrade panel to > >finalize the tile lay. > > > >I realized that now one has to use the buttons at the top of the upgrade > > > >panel for tile/token laying, but the buttons at the bottom of the OR > >window for later actions (payout, buy trains etc). > > > >My suggestion is to make UI easier is: > > > >A) Remove the button panel at the bottom of the OR window. > > > >B) Move the undo/redo buttons to the bottom of the upgrade panel (always > > > >visible) > > > >C) Move the action buttons (payout/withhold/buy train) to the top of the > > > >upgrade panel. This implies that the action buttons will change > >depending on the activity. > > > >Open question is where to move "Buy Private". One possibility is to move > > > >the buy Private button to a entry of the special menu? Or a separate > >entry of the menu? Other ideas? > > > >Feedback and other/further ideas are welcome. > > > >Stefan > > > >Attachment: UI_buttons_comments.png > > > >----------------------------------------------------------- > ------------------- > >Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > >by Intel and developed in partnership with Slashdot Media, is your hub for > >all > >things parallel software development, from weekly thought leadership blogs > >to > >news, videos, case studies, tutorials and more. Take a look and join the > > > >conversation now. http://goparallel.sourceforge.net/ > >_______________________________________________ > >Rails-devel mailing list > >Rai...@li... > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: <com...@ip...> - 2015-03-10 10:31:39
|
"buy privates" sounds like an action to me - why not group it with them, but have it only visible when relevant? Mike >-- Original Message -- >Date: Tue, 10 Mar 2015 09:58:58 +0100 >From: Stefan Frey <ste...@we...> >To: Development list for Rails: an 18xx game > <rai...@li...>, rai...@li... >Subject: [Rails-devel] Rails 2.0 discussion: Changes to OR Window? >Reply-To: "Development list for Rails: an 18xx game" > <rai...@li...> > > >Hi, >to get more feedback on the UI, I will try to make some more suggestions > >how to improve the Rails 2.0 UI. > >Those who tried the 2.0 beta already know that the buttons Confirm/Skip >have been move to the top of the upgrade panel and are always visible >(green circle in the attached image). > >First reason for that was to avoid scrolling down the upgrade panel to >finalize the tile lay. > >I realized that now one has to use the buttons at the top of the upgrade > >panel for tile/token laying, but the buttons at the bottom of the OR >window for later actions (payout, buy trains etc). > >My suggestion is to make UI easier is: > >A) Remove the button panel at the bottom of the OR window. > >B) Move the undo/redo buttons to the bottom of the upgrade panel (always > >visible) > >C) Move the action buttons (payout/withhold/buy train) to the top of the > >upgrade panel. This implies that the action buttons will change >depending on the activity. > >Open question is where to move "Buy Private". One possibility is to move > >the buy Private button to a entry of the special menu? Or a separate >entry of the menu? Other ideas? > >Feedback and other/further ideas are welcome. > >Stefan > >Attachment: UI_buttons_comments.png > >------------------------------------------------------------------------------ >Dive into the World of Parallel Programming The Go Parallel Website, sponsored >by Intel and developed in partnership with Slashdot Media, is your hub for >all >things parallel software development, from weekly thought leadership blogs >to >news, videos, case studies, tutorials and more. Take a look and join the > >conversation now. http://goparallel.sourceforge.net/ >_______________________________________________ >Rails-devel mailing list >Rai...@li... >https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Stefan F. <ste...@we...> - 2015-03-10 08:59:22
|
Hi, to get more feedback on the UI, I will try to make some more suggestions how to improve the Rails 2.0 UI. Those who tried the 2.0 beta already know that the buttons Confirm/Skip have been move to the top of the upgrade panel and are always visible (green circle in the attached image). First reason for that was to avoid scrolling down the upgrade panel to finalize the tile lay. I realized that now one has to use the buttons at the top of the upgrade panel for tile/token laying, but the buttons at the bottom of the OR window for later actions (payout, buy trains etc). My suggestion is to make UI easier is: A) Remove the button panel at the bottom of the OR window. B) Move the undo/redo buttons to the bottom of the upgrade panel (always visible) C) Move the action buttons (payout/withhold/buy train) to the top of the upgrade panel. This implies that the action buttons will change depending on the activity. Open question is where to move "Buy Private". One possibility is to move the buy Private button to a entry of the special menu? Or a separate entry of the menu? Other ideas? Feedback and other/further ideas are welcome. Stefan |
From: Stefan F. <ste...@we...> - 2015-03-07 19:32:37
|
First beta release for Rails 2.0! This release features the full rule-compliant tile and token lay engine and user interface. In addition Martin has merged all 1880 changes from latest rails 1.9.0 release, so it should be usable for 1880 as well. So please test the beta release and provide feedback on both usability and bugs of the new tile and token laying interface. Stefan *** Testing of Rails 2.0 beta 1 possible via Webstart or Download * Webstart the beta release: http://rails.sf.net/webstart/rails.jnlp * Download the beta release: Download the single jar and start it directly (by double-click or command line "java -jar" command). http://sourceforge.net/projects/rails/files/Rails/2.0/ *** Remarks - More information and the current 2.0 roadmap (including list of bugs) is linked on project web page http://rails.sourceforge.net - Most of my own manual testing was done on 1830, 1835 and 1856. - All automatic test games run. - Some reported bugs from previous 2.0 Alpha releases are still open. |
From: Stefan F. <ste...@we...> - 2015-02-20 10:06:18
|
After adding back support for Bonus Token lay, the next 2.0 release is the first beta, thus no new functionality will be added, only minor UI fixes/improvements and bug fixes will be done. The last alpha release which I had announced, got lost due to the work of the 1880 integration into the rails 2 branch, which is still ongoing. I hope that the beta phase will be much shorter compared to the alpha phase, at least there will be more frequent releases ;-) Thanks for your patience and help, Stefan |
From: Stefan F. <ste...@we...> - 2015-02-09 19:21:16
|
For those of you, who only subscribe to Rails-devel, I forward this Rails 1.9.0 release mail from Martin Brumm. A special thanks to him for his efforts to take on the challenging task to implement 1880 and hunt down the occuring bugs. Downloads as usual on Sourceforge. My hope is that development gets a little simpler in 2.0, however please do not expects any miracles. ;-) Stefan Release message from Martin Brumm: From the release notes: Rails release 1.9 This is a minor/major release fixing the following bugs: - 1880 : Fixed bug in placement of home bases for major companies Fixed bug in handling of home base token on Beijing Hex Fixed bug in starting a company with 40% share and investor and not receiving full cash Added Log messages for the protocol regarding the Cash received upon a company reaching 50 percent. Now the Expresstrains should be calculated correctly -> Thanks to Stefan Frey Numerous Games got improved by additions from Frederick Weld. Thank you to all our testers. ( The group at Winterburg for the Cash Problem, the Hamburg crew for the Express train and Game ending problem, and the BGG PbEM group for the Beijing tile upgrade and home base token problem). Special thanks and an apology to Frederick Weld. His fixes got overlooked in the past. Please report any bugs you find on the mailinglist as usual. Unless theres a game breaking bug for which no workaround exists or can found, this will be the last release of the 1.x-Branch. WORK WILL CONTINUE ON RAILS 2.0 Thank you for the patience and feedback. Martin |
From: Stefan F. <ste...@we...> - 2015-01-27 10:12:06
|
Some of you might have wondered, when the next alpha release is due? Actually I focussed on the UI generation of UI tables that are used both in the Status (ShareRound) and Map (OperatingRound) windows. In Rails 1.x they are wired by a lot of manually written code with lots of code duplication. My target was to create a encapsulated approach to generate those tables using a fluent interface (API) similar to the ones of that used by Google's Guava library, which I really love to use. I have now reached a state, where I am able to duplicate the StartRoundWindow using only a few lines of code (everything else done by the generic table classes): Someone interested in details can have a look at StartRoundStatus class in package rails.ui.swing how to create such a table. All implementing classes for such a table are in rails.ui.swing.core. However it will still take some time to get everything rewritten using the new approach and I do not want to delay the Rails 2.0 releases further. So I will refocus on getting Rails 2.0 out-of-the-door and continue fixing the open issues already reported. For testing the new UI creation I needed a game similar to 1830, however 1830 is now pretty complex beast due to the variants. I could have used 18Kaas, however after all the generic programming, I preferred to work a little closer to 18xx and decided to implement 18NL (an 1830 adaptation to the Netherlands, a very early design of Helmut Ohley, rules and pieces available to download on his webpage). So expect in the next alpha release a working version of 18NL, which will be used for testing the new UI elements. All other 18xx of Rails will keep using the old UI until the new works reliable. I expect the next alpha release of Rails 2.0 the upcoming weekend, so if someone has something close to finish, consider to merge it to rails_2_develop. Stefan |
From: Stefan F. <ste...@we...> - 2015-01-06 10:29:11
|
Martin: just to inform you: I am currently looking into the implementation of the 1844/1854 as well. We could easily share efforts. Before that I will still focus on the upcoming Rails 2.0 release ;-) Stefan On 01/05/2015 06:04 PM, Martin Brumm wrote: > Am 05.01.2015 um 17:24 schrieb Stefan Frey: >> Martin: >> currently there is no explicit support for multiple maps per game. >> >> However you could consider placing both maps on one Rails map by >> choosing non-overlapping coordinates. >> >> Is there a specific 18xx you are thinking of (1854?)? >> >> Stefan >> >> >> On 01/05/2015 11:42 AM, Martin Brumm wrote: >>> Hello Erik, Brett, Stefan, >>> >>> is it currently possible for Rails to support more than one Map per game ? >>> >>> Regards, >>> Martin >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> > Hi Stefan, > > yes 1854 came to my mind, had some games between the years playtesting > the upcoming new version from Lookout Games. > > And ye it will be a challenge agin to implment this as well as 1844. > > Regards, > Martin > > P.s. I'll try the Mapoffset suggestion with bot maps on one page. > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Martin B. <dr....@t-...> - 2015-01-05 17:04:13
|
Am 05.01.2015 um 17:24 schrieb Stefan Frey: > Martin: > currently there is no explicit support for multiple maps per game. > > However you could consider placing both maps on one Rails map by > choosing non-overlapping coordinates. > > Is there a specific 18xx you are thinking of (1854?)? > > Stefan > > > On 01/05/2015 11:42 AM, Martin Brumm wrote: >> Hello Erik, Brett, Stefan, >> >> is it currently possible for Rails to support more than one Map per game ? >> >> Regards, >> Martin >> >> >> >> ------------------------------------------------------------------------------ >> Hi Stefan, yes 1854 came to my mind, had some games between the years playtesting the upcoming new version from Lookout Games. And ye it will be a challenge agin to implment this as well as 1844. Regards, Martin P.s. I'll try the Mapoffset suggestion with bot maps on one page. |
From: Stefan F. <ste...@we...> - 2015-01-05 16:24:45
|
Martin: currently there is no explicit support for multiple maps per game. However you could consider placing both maps on one Rails map by choosing non-overlapping coordinates. Is there a specific 18xx you are thinking of (1854?)? Stefan On 01/05/2015 11:42 AM, Martin Brumm wrote: > Hello Erik, Brett, Stefan, > > is it currently possible for Rails to support more than one Map per game ? > > Regards, > Martin > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Martin B. <dr....@t-...> - 2015-01-05 10:42:32
|
Hello Erik, Brett, Stefan, is it currently possible for Rails to support more than one Map per game ? Regards, Martin |
From: Stefan F. <ste...@we...> - 2014-12-10 16:56:02
|
Frederick: Exactly my target was to target the middle ground: Keep things simple for designers, but still powerful enough to cover variations by program code. However expect nothing before 2.1, as I realized that the rendering quality of SVGSalamander is not good enough for Rails. This was the result after some tests that replaced batik by SVGSalamander for tile display. If anyone is interested I can push the branch to the public repo. So I will keep batik and will make myself more comfortable with the library which is definitely powerful, but but a little over-engineered. Stefan On 12/09/2014 06:12 PM, Frederick Weld wrote: > Stefan: > You propose that the degree of rails/svg-map coupling can vary and that > this can be configured in the game's xmls. I couldn't think of a better > proposal as this will effectively combine the best of the two extremes I > mentioned earlier! > > As a proof point of your config redesign, you could take the new 1830 > basegame map and check whether it can be adjusted in the game config for > some minor variants (Reading, Pere Marquette) that do not resize the map > (as Coalfields does). If this does not work, you could also make a copy > of the basegame map, label it 1830 template map and remove all parts > that are not shared by all of these variants. If your redesign > succeeded, you would not only have a complete suite of 1830 maps. On top > of that, 1830 would serve as an example how to add variable maps to > rails. You would have killed two birds with one stone! > > -- Frederick > > On Tue, Dec 9, 2014 at 4:57 PM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Frederick: > you also have very valid points: I will surely respect the freedom of > the designer to add anything that is not dynamic. So everything that is > now printed on a 18xx map (including the offboard values) can be defined > by the designer. > I do not want to interfere there. > > However two things I want to add: > > (1) Make it easier for the designer by getting a kind of "template" map > using all information from the xml for consistency. It would also make > things easier for designers to choose the correct scaling (especially > they could paste and copy tiles from the rails repository or reuse parts > of existing maps). > > (2) Do not require the designer to define all elements, which could be > potentially created by Rails: E.g. coordinates, pre-painted tiles, tile > costs, revenue values on specific tiles. Think e.g. variants like in > 1856 where only the revenue value of Toronto is changed. Do we need an > additional background map for this? Or the variant with alternative > destinations etc. However it could be optional, thus it can be defined > in the xml files, if those come from the map or a created by Rails. > > (3) We can keep the current background map option, which is basically a > plain background image, with scaling and translation option which is a > very loose coupling. > > The good thing is that Rails is very well adopted to live with many > variations, thus the increased complexity can very well be handled. > > Stefan > > > > On 12/09/2014 03:57 PM, Frederick Weld wrote: > > Stefan: > > All these are valid points. I guess that this is all about the > decision > > into which direction rails should go with respect to the map: > > > > (1) Leave it as it is (loosely coupled, working with arbitrary > svgs). An > > option here is to add a tool for exporting arbitrary > map/companyMgr xmls > > as svg prototypes. > > > > (2) Establish a closer link between the map svg and the game. > This means > > that the map has to fulfill specific requirements like having a > specific > > coordinate system or omitting information which is drawn by the game > > instead or even further requirements that lead to even tighter > integration. > > > > As I said, option (1) would be ok for me. The tool would assist the > > designer to some degree. > > > > Regarding option (2), I wouldn't like it that much. As an > example, the > > designer would also want to define the positioning/style of the > offboard > > values. Removing the aforementioned redundancy would only be > possible if > > the game/design integration was much tighter, eg., using text/value > > place holders in the svg design. But then the map designer does not > > control every aspect of the representation any more (he might want to > > adjust the style depending on the text/value's length etc.). > > > > Currently, the only aspect which is according to (2) are the > row/column > > coordinates which I omitted from my svgs as a result. This is ok > for me > > as I seldom need them, but anything beyond would really be > detrimental > > from my point of view. > > > > As for the token svgs: I thought about that (incl. code to > display them > > instead of imperative token drawing) some years ago but I didn't move > > forward with that. The reasoning behind this was as follows: > Other parts > > of the game (especially Game status window) have a textual-only > > representation of the companies. Depending on the token art, it > could be > > difficult to match it to the company name. So either each and > every part > > of the UI gets these svg tokens or the tokens remain text based. > > Personally, I'm quite happy with the current solution. > > > > -- Frederick > > > > > > On Tue, Dec 9, 2014 at 11:50 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > Frederick: > > my goal is both to shorten time for the designer and make > e.g. scaling > > problems less an issue. > > > > Would you not think that the hex grid will already help other > designers > > to know how large the map size will be. So it is less an > issue to scale > > and translate which currently is far from perfect. > > > > Map.xml is not reliable, as it is hardly used so far. However > it is not > > that diffcult to get that up-to-date. However most likely it > will not > > add that automatically, as due to text scaling and > positioning it is > > better for a human to decide where and how to put it. > > > > But offboard values should better be derived from xml, as it > avoids > > double definition, which is really confusing for players (the > same is > > not true for city names which usually have no real impact in > 18xx). > > > > And know I will not manipulate Tokens by code and I would > only like to > > place tokens on tiles by code. This requires tiles to adhere > a specific > > structure (to locate the token slots), not potential tokens > svg files. > > Would you be interested to design tokens for Rails in svg? It > is easy to > > add code to support user-supplied tokens, if anyone is > interested to > > create some. > > > > Stefan > > > > > > On 12/09/2014 11:31 AM, Frederick Weld wrote: > > > Stefan: > > > If your goal is to shorten the time a designer needs for a > new svg, > > > these ideas would certainly contribute to that. Although, > for me, > > > recreating the hex grid amounted to only about 10% of the > time, the > > > remainder being creating coastlines/rivers and > design/placing of shapes. > > > > > > Map.xml's city/town names are also not reliable - at least > town names > > > are never included. > > > > > > So, as a result, I wouldn't create more svgs if such svg > pregeneration > > > functionality existed. But on the other hand, it would save > me some > > > amount of time if I created one. > > > > > > For doing more with the svg (incorporating artful tokens > etc.), I have > > > my doubts about that. It would be too easy for a WYSIWYG > editor to mess > > > this up. Such svgs would have to be edited in an xml editor > after the > > > designer had completed his initial work... > > > > > > -- Frederick > > > > > > On Tue, Dec 9, 2014 at 11:09 AM, Stefan Frey > <ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>> wrote: > > > > > > Frederick, > > > no I am realistic that a designer of a map cares more > about > > the SVG > > > structure than you already did. I only wondered how > far you > > went, most > > > likely you define the upper limit of carefulness. ;-) > > > > > > My goal is to separate those parts of the background map, > > which are > > > better generated/manipulated by > > > the code and which by the human designer. > > > > > > My current thoughts are: > > > > > > * A hex grid SVG definition should be generated by a > program. > > There are > > > SVG online generators (e.g. > > > http://axiscity.hexamon.net/users/isomage/misc/svg-hex.cgi), > > however I > > > assume coding an own one, is not too difficult. This would > > allow to > > > generate a hexgrid as a SVG based on Rails map > definitions. > > > > > > * The hex grid could then be imported by a designer to > add the > > > background map. If Inkscape is used it is easy to separate > > the two parts > > > (grid and map) by layers. > > > > > > * It is possible to add another SVG layer that shows > the Rails > > > predefined tiles on the hexgrid. This would make the > > designing task > > > easier, at it would show, what content is expected in > each hex. > > > By using layers, it can be easily separated later on. > > > > > > I still have to think more about tiles. I would like to > > change tiles > > > that it is possible to change them by code. This would > imply > > that the > > > base structure has to be defined manually to make code > > manipulation > > > easier. The reason for that would be e.g. to add > tokens, add > > offboard > > > values, city names, all stuff that is already contained in > > the xml > > > definitions. > > > > > > What do you (and others think) about that? > > > > > > Stefan > > > > > > > > > Frederick Weld <fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > > <mailto:fre...@go... <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>>>schrieb: > > > > > > Stefan: > > > Actually, I use Inkscape as a WYSIWYG tool and do not > > bother about > > > redundancies in the residual svg as long as the file > > size is less > > > than 100k. I keep the layers and grouping in the > pushed svg > > > versions > > > so that anyone could easily alter aspects of the svg. > > > > > > A lot of your questions are pointing into the > direction > > that the > > > designer needs to care more about the svg model. That > > could come > > > with a lot of advantages but keep in mind that any > > compulsion to do > > > this could potentially turn away WYSIWYG > designers. Here > > are some > > > answers: > > > > > > - The ids are auto-assigned but could be changed > within > > the tool. > > > > > > - I don't think that Inkscape can be forced to retain > > the syntax of > > > tiles copied from outside. > > > > > > - I am not aware of any in-tool support for css, > but I could > > > imagine > > > that other tools (or even Inkscape with direct svg > > editing) provide > > > for that. > > > > > > - I use separate hexes instead of a hex grid since I > > often need the > > > hex definition to add a filling (eg., prelaid > tiles at > > the coast). > > > But I imagine that other designs could differ > regarding this > > > aspect. > > > > > > -- Frederick > > > > > > On Mon, Dec 8, 2014 at 6:09 PM, Stefan > > Frey<ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... > <mailto:ste...@we...> <mailto:ste...@we... > <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>>> wrote: > > > > > > Frederick: > > > thanks a lot. Your feedback is really helpful. > > > > > > And I appreciate your functional but good-looking > > design. > > > > > > I am currently looking into how interact with the > > svg maps from > > > inside > > > the code. > > > > > > Maybe some questions up-front: > > > > > > * How did you (or Inkscape) assing ids to your > > elements? Is > > > there any > > > system to it, that relates to the actual 18xx > > definitions? > > > > > > * Is it possible to force Inkscape to use > pre-defined > > > styles for > > > attributes (inline or external CSS) to reduce the > > replication > > > inside the > > > svg? > > > > > > * Inkscape seems to change the syntax of tile > > definitions > > > at the > > > time > > > copying (e.g. uses relative coordinates > instead of > > absolute > > > coordinates > > > for the path definitions). > > > > > > * It seems that it is possible to save it as > plain > > svg without > > > quality > > > loss (however it prevents Inkscape to > identify the layer > > > information). > > > > > > * Do you have a good idea to avoid the > duplication > > of drawing > > > the hex > > > borders? I think it would be a good idea to > separate > > > drawing the hex > > > grid from the hex content to avoid that. > > > > > > I do not want to change the map code too much > in 2.0, > > > except for > > > replacing batik. However I want to improve > that in > > the next > > > upcoming > > > releases. So I am still very open for ideas. > > > > > > Stefan > > > > > > > > > On 12/05/2014 03:12 PM, Frederick Weld wrote: > > > > Stefan: > > > > The hexes have the same size as the tile svgs. > > This makes it > > > possible to > > > > just copy required tiles (Altoona...) from the > > tile svg into > > > the map. > > > > > > > > These tile svgs are the one very important > > element of reuse. > > > > > > > > I reuse further parts from my former maps > - but > > this is > > > rather pure > > > > design (shape/color patterns for > rendering...). > > > > > > > > I do not use any specific coordinate > system and, as a > > > result, > > > I have to > > > > calibrate the maps within the game to get the > > x/y/scale > > > parameters. This > > > > is no drawback though, as I often want to > be able to > > > make the > > > decision > > > > how much "padding" the grid needs within > my map's > > layout... > > > > > > > > -- Frederick > > > > > > > > On Fri, Dec 5, 2014 at 2:51 PM, Stefan Frey > > > <ste...@we... > <mailto:ste...@we...> <mailto:ste...@we... > <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>> > > > > <mailto:ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>>>> wrote: > > > > > > > > Frederick: > > > > thanks for your feedback. > > > > I assumed this by the size of the files, > > however I > > > had no > > > time yet > > > > to look into details. > > > > > > > > One further question: What coordinates > did you > > > choose for > > > your maps? > > > > Is it identical across your maps? What > is the > > size > > > of one > > > hexagon in > > > > those coordinates. Have you already > started > > to create > > > single tiles > > > > for reuse? I am keen on replacing the > > existing tile > > > creation process > > > > by a simpler one. > > > > > > > > Most likely you can guess where I am > hinting > > at, but I > > > will give > > > > more details on Sunday. > > > > > > > > Great work, > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > > Frederick Weld > <fre...@go... <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>>> > > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>>>>>schrieb: > > > > > > > > Stefan: > > > > I use Inkscape for > creating/editing the > > vector maps. > > > They are > > > > stored in svg format. I couldn't > imagine > > any other > > > combination > > > > which would fit our needs here in a > > better manner. > > > > > > > > SVG files are verbose but their > size gets > > shrunk by > > > compression > > > > to 10-15% of the original size. My > maps are > > > <100k when > > > > compressed. Hence, I do not think > this is > > a real > > > issue. > > > > > > > > However, the situation is > different for > > converted > > > maps (in > > > > rails, e.g, 18EU, 18AL). They > include a > > lot of > > > superfluous paths > > > > (including paths instead of text) > and get > > > bloated and > > > slow to > > > > draw as a result. That (and copyright > > > considerations) > > > is why I > > > > always build my maps from the scratch. > > > > > > > > The svg lib could be exchanged, of > > course. But as a > > > > prerequisite, the new lib should be > > regression-free > > > with respect > > > > to exiting background maps. > > > > > > > > -- Frederick > > > > > > > > On Thu, Dec 4, 2014 at 12:14 PM, > Stefan > > > Frey<ste...@we... > <mailto:ste...@we...> <mailto:ste...@we... > <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>> > > > > <mailto:ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>>>>> > > > wrote: > > > > > > > > Frederick: > > > > we could do that later on. Most > > people now > > > know that > > > > rails_2_develop is > > > > the (default) branch for rails 2. > > > > > > > > My (future) release strategy > is based on > > > > > > > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > > > > > However I still consider > moving the > > git repo > > > (only the repo, > > > > not the > > > > other parts) to github, then this > > will happen > > > with the > > > > official rails > > > > 2.0 release. > > > > > > > > I am looking forward to seeing > more maps > > > from you. > > > > > > > > One question: In which format and > > tools do you > > > create your > > > > maps? > > > > > > > > Most likely you will know that I > > intend to > > > replace the Batik > > > > lib soon. > > > > However which long-run > strategy to ch > > oose > > > how display > > > > maps/tiles for Rails. > > > > > > > > In the short-run I will simply > > replace Batik > > > by a > > > more > > > > light-weight SVG > > > > library, but I am open to > > recommendations. > > > > > > > > Stefan > > > > > > > > > > > > On 12/04/2014 10:16 AM, Frederick > > Weld wrote: > > > > > Stefan: > > > > > There is no standard 1830 > map yet. > > I will > > > probably do > > > > that after the > > > > > Coalfield map has been reviewed > > (bgg) and > > > thoroughly > > > > play-tested. > > > > > > > > > > How about labeling > rails_2_develop > > as master? > > > Then the > > > > meaning would be > > > > > clear: Current state of > validated > > development > > > which is > > > > eligible for the > > > > > next release. > > > > > > > > > > -- Frederick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Download BIRT iHub F-Type - > The Free > > > Enterprise-Grade > > > > BIRT Server > > > > > from Actuate! Instantly > > Supercharge Your > > > Business Reports > > > > and Dashboards > > > > > with Interactivity, Sharing, > > Native Excel > > > Exports, App > > > > Integration & more > > > > > Get technology previously > reserved for > > > billion-dollar > > > > corporations, FREE > > > > > > > > > > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rails-devel mailing list > > > > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>>> > > > > > > > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - > The Free > > > Enterprise-Grade BIRT > > > > Server > > > > from Actuate! Instantly > Supercharge Your > > > Business > > > Reports > > > > and Dashboards > > > > with Interactivity, Sharing, > Native Excel > > > Exports, App > > > > Integration & more > > > > Get technology previously > reserved for > > > billion-dollar > > > > corporations, FREE > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > > Enterprise-Grade > > > BIRT > > > > Server from Actuate! Instantly > > Supercharge Your > > > Business Reports > > > > and Dashboards with Interactivity, > Sharing, > > > Native Excel > > > > Exports, App Integration & more Get > > technology > > > previously > > > > reserved for billion-dollar > corporations, > > > > > > > > > > > > > FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > > > > > > > > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > Rails-devel mailing > > > lis...@li... > <mailto:lis...@li...> > > <mailto:lis...@li... > <mailto:lis...@li...>> > > > <mailto:lis...@li... > <mailto:lis...@li...> > > <mailto:lis...@li... > <mailto:lis...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>>>https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade > > > BIRT Server > > > > from Actuate! Instantly Supercharge > Your Business > > > Reports > > > and Dashboards > > > > with Interactivity, Sharing, Native Excel > > Exports, App > > > Integration & > > > > more > > > > Get technology previously reserved for > > billion-dollar > > > corporations, FREE > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>>> > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free Enterprise-Grade > > > BIRT Server > > > > from Actuate! Instantly Supercharge Your Business > > > Reports and > > > Dashboards > > > > with Interactivity, Sharing, Native Excel Exports, App > > > Integration & more > > > > Get technology previously reserved for billion-dollar > > > corporations, FREE > > > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade BIRT > > > Server > > > from Actuate! Instantly Supercharge Your Business > > Reports and > > > Dashboards > > > with Interactivity, Sharing, Native Excel > Exports, App > > > Integration & more > > > Get technology previously reserved for > billion-dollar > > > corporations, FREE > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade > > BIRT Server > > > from Actuate! Instantly Supercharge Your Business > > Reports and > > > Dashboards with Interactivity, Sharing, Native Excel > > Exports, App > > > Integration & more Get technology previously > reserved for > > > billion-dollar corporations, > > > > > > > > > FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > Rails-devel mailing list > > > > > > Rai...@li...https://lists.sourceforge.net/lists/listinfo/rails-devel > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > > with Interactivity, Sharing, Native Excel Exports, App Integration & > > > more > > > Get technology previously reserved for billion-dollar corporations, FREE > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > > Get technology previously reserved for billion-dollar > > corporations, FREE > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > with Interactivity, Sharing, Native Excel Exports, App > Integration & > > more > > Get technology previously reserved for billion-dollar > corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > with Interactivity, Sharing, Native Excel Exports, App > Integration & more > > Get technology previously reserved for billion-dollar > corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & > more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Frederick W. <fre...@go...> - 2014-12-09 17:12:32
|
Stefan: You propose that the degree of rails/svg-map coupling can vary and that this can be configured in the game's xmls. I couldn't think of a better proposal as this will effectively combine the best of the two extremes I mentioned earlier! As a proof point of your config redesign, you could take the new 1830 basegame map and check whether it can be adjusted in the game config for some minor variants (Reading, Pere Marquette) that do not resize the map (as Coalfields does). If this does not work, you could also make a copy of the basegame map, label it 1830 template map and remove all parts that are not shared by all of these variants. If your redesign succeeded, you would not only have a complete suite of 1830 maps. On top of that, 1830 would serve as an example how to add variable maps to rails. You would have killed two birds with one stone! -- Frederick On Tue, Dec 9, 2014 at 4:57 PM, Stefan Frey <ste...@we...> wrote: > Frederick: > you also have very valid points: I will surely respect the freedom of > the designer to add anything that is not dynamic. So everything that is > now printed on a 18xx map (including the offboard values) can be defined > by the designer. > I do not want to interfere there. > > However two things I want to add: > > (1) Make it easier for the designer by getting a kind of "template" map > using all information from the xml for consistency. It would also make > things easier for designers to choose the correct scaling (especially > they could paste and copy tiles from the rails repository or reuse parts > of existing maps). > > (2) Do not require the designer to define all elements, which could be > potentially created by Rails: E.g. coordinates, pre-painted tiles, tile > costs, revenue values on specific tiles. Think e.g. variants like in > 1856 where only the revenue value of Toronto is changed. Do we need an > additional background map for this? Or the variant with alternative > destinations etc. However it could be optional, thus it can be defined > in the xml files, if those come from the map or a created by Rails. > > (3) We can keep the current background map option, which is basically a > plain background image, with scaling and translation option which is a > very loose coupling. > > The good thing is that Rails is very well adopted to live with many > variations, thus the increased complexity can very well be handled. > > Stefan > > > > On 12/09/2014 03:57 PM, Frederick Weld wrote: > > Stefan: > > All these are valid points. I guess that this is all about the decision > > into which direction rails should go with respect to the map: > > > > (1) Leave it as it is (loosely coupled, working with arbitrary svgs). An > > option here is to add a tool for exporting arbitrary map/companyMgr xmls > > as svg prototypes. > > > > (2) Establish a closer link between the map svg and the game. This means > > that the map has to fulfill specific requirements like having a specific > > coordinate system or omitting information which is drawn by the game > > instead or even further requirements that lead to even tighter > integration. > > > > As I said, option (1) would be ok for me. The tool would assist the > > designer to some degree. > > > > Regarding option (2), I wouldn't like it that much. As an example, the > > designer would also want to define the positioning/style of the offboard > > values. Removing the aforementioned redundancy would only be possible if > > the game/design integration was much tighter, eg., using text/value > > place holders in the svg design. But then the map designer does not > > control every aspect of the representation any more (he might want to > > adjust the style depending on the text/value's length etc.). > > > > Currently, the only aspect which is according to (2) are the row/column > > coordinates which I omitted from my svgs as a result. This is ok for me > > as I seldom need them, but anything beyond would really be detrimental > > from my point of view. > > > > As for the token svgs: I thought about that (incl. code to display them > > instead of imperative token drawing) some years ago but I didn't move > > forward with that. The reasoning behind this was as follows: Other parts > > of the game (especially Game status window) have a textual-only > > representation of the companies. Depending on the token art, it could be > > difficult to match it to the company name. So either each and every part > > of the UI gets these svg tokens or the tokens remain text based. > > Personally, I'm quite happy with the current solution. > > > > -- Frederick > > > > > > On Tue, Dec 9, 2014 at 11:50 AM, Stefan Frey <ste...@we... > > <mailto:ste...@we...>> wrote: > > > > Frederick: > > my goal is both to shorten time for the designer and make e.g. > scaling > > problems less an issue. > > > > Would you not think that the hex grid will already help other > designers > > to know how large the map size will be. So it is less an issue to > scale > > and translate which currently is far from perfect. > > > > Map.xml is not reliable, as it is hardly used so far. However it is > not > > that diffcult to get that up-to-date. However most likely it will not > > add that automatically, as due to text scaling and positioning it is > > better for a human to decide where and how to put it. > > > > But offboard values should better be derived from xml, as it avoids > > double definition, which is really confusing for players (the same is > > not true for city names which usually have no real impact in 18xx). > > > > And know I will not manipulate Tokens by code and I would only like > to > > place tokens on tiles by code. This requires tiles to adhere a > specific > > structure (to locate the token slots), not potential tokens svg > files. > > Would you be interested to design tokens for Rails in svg? It is > easy to > > add code to support user-supplied tokens, if anyone is interested to > > create some. > > > > Stefan > > > > > > On 12/09/2014 11:31 AM, Frederick Weld wrote: > > > Stefan: > > > If your goal is to shorten the time a designer needs for a new svg, > > > these ideas would certainly contribute to that. Although, for me, > > > recreating the hex grid amounted to only about 10% of the time, the > > > remainder being creating coastlines/rivers and design/placing of > shapes. > > > > > > Map.xml's city/town names are also not reliable - at least town > names > > > are never included. > > > > > > So, as a result, I wouldn't create more svgs if such svg > pregeneration > > > functionality existed. But on the other hand, it would save me some > > > amount of time if I created one. > > > > > > For doing more with the svg (incorporating artful tokens etc.), I > have > > > my doubts about that. It would be too easy for a WYSIWYG editor to > mess > > > this up. Such svgs would have to be edited in an xml editor after > the > > > designer had completed his initial work... > > > > > > -- Frederick > > > > > > On Tue, Dec 9, 2014 at 11:09 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...> > > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > > > Frederick, > > > no I am realistic that a designer of a map cares more about > > the SVG > > > structure than you already did. I only wondered how far you > > went, most > > > likely you define the upper limit of carefulness. ;-) > > > > > > My goal is to separate those parts of the background map, > > which are > > > better generated/manipulated by > > > the code and which by the human designer. > > > > > > My current thoughts are: > > > > > > * A hex grid SVG definition should be generated by a program. > > There are > > > SVG online generators (e.g. > > > http://axiscity.hexamon.net/users/isomage/misc/svg-hex.cgi), > > however I > > > assume coding an own one, is not too difficult. This would > > allow to > > > generate a hexgrid as a SVG based on Rails map definitions. > > > > > > * The hex grid could then be imported by a designer to add the > > > background map. If Inkscape is used it is easy to separate > > the two parts > > > (grid and map) by layers. > > > > > > * It is possible to add another SVG layer that shows the Rails > > > predefined tiles on the hexgrid. This would make the > > designing task > > > easier, at it would show, what content is expected in each > hex. > > > By using layers, it can be easily separated later on. > > > > > > I still have to think more about tiles. I would like to > > change tiles > > > that it is possible to change them by code. This would imply > > that the > > > base structure has to be defined manually to make code > > manipulation > > > easier. The reason for that would be e.g. to add tokens, add > > offboard > > > values, city names, all stuff that is already contained in > > the xml > > > definitions. > > > > > > What do you (and others think) about that? > > > > > > Stefan > > > > > > > > > Frederick Weld <fre...@go... > > <mailto:fre...@go...> > > > <mailto:fre...@go... > > <mailto:fre...@go...>>>schrieb: > > > > > > Stefan: > > > Actually, I use Inkscape as a WYSIWYG tool and do not > > bother about > > > redundancies in the residual svg as long as the file > > size is less > > > than 100k. I keep the layers and grouping in the pushed > svg > > > versions > > > so that anyone could easily alter aspects of the svg. > > > > > > A lot of your questions are pointing into the direction > > that the > > > designer needs to care more about the svg model. That > > could come > > > with a lot of advantages but keep in mind that any > > compulsion to do > > > this could potentially turn away WYSIWYG designers. Here > > are some > > > answers: > > > > > > - The ids are auto-assigned but could be changed within > > the tool. > > > > > > - I don't think that Inkscape can be forced to retain > > the syntax of > > > tiles copied from outside. > > > > > > - I am not aware of any in-tool support for css, but I > could > > > imagine > > > that other tools (or even Inkscape with direct svg > > editing) provide > > > for that. > > > > > > - I use separate hexes instead of a hex grid since I > > often need the > > > hex definition to add a filling (eg., prelaid tiles at > > the coast). > > > But I imagine that other designs could differ regarding > this > > > aspect. > > > > > > -- Frederick > > > > > > On Mon, Dec 8, 2014 at 6:09 PM, Stefan > > Frey<ste...@we... <mailto:ste...@we...> > > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>>> wrote: > > > > > > Frederick: > > > thanks a lot. Your feedback is really helpful. > > > > > > And I appreciate your functional but good-looking > > design. > > > > > > I am currently looking into how interact with the > > svg maps from > > > inside > > > the code. > > > > > > Maybe some questions up-front: > > > > > > * How did you (or Inkscape) assing ids to your > > elements? Is > > > there any > > > system to it, that relates to the actual 18xx > > definitions? > > > > > > * Is it possible to force Inkscape to use pre-defined > > > styles for > > > attributes (inline or external CSS) to reduce the > > replication > > > inside the > > > svg? > > > > > > * Inkscape seems to change the syntax of tile > > definitions > > > at the > > > time > > > copying (e.g. uses relative coordinates instead of > > absolute > > > coordinates > > > for the path definitions). > > > > > > * It seems that it is possible to save it as plain > > svg without > > > quality > > > loss (however it prevents Inkscape to identify the > layer > > > information). > > > > > > * Do you have a good idea to avoid the duplication > > of drawing > > > the hex > > > borders? I think it would be a good idea to separate > > > drawing the hex > > > grid from the hex content to avoid that. > > > > > > I do not want to change the map code too much in 2.0, > > > except for > > > replacing batik. However I want to improve that in > > the next > > > upcoming > > > releases. So I am still very open for ideas. > > > > > > Stefan > > > > > > > > > On 12/05/2014 03:12 PM, Frederick Weld wrote: > > > > Stefan: > > > > The hexes have the same size as the tile svgs. > > This makes it > > > possible to > > > > just copy required tiles (Altoona...) from the > > tile svg into > > > the map. > > > > > > > > These tile svgs are the one very important > > element of reuse. > > > > > > > > I reuse further parts from my former maps - but > > this is > > > rather pure > > > > design (shape/color patterns for rendering...). > > > > > > > > I do not use any specific coordinate system and, > as a > > > result, > > > I have to > > > > calibrate the maps within the game to get the > > x/y/scale > > > parameters. This > > > > is no drawback though, as I often want to be able > to > > > make the > > > decision > > > > how much "padding" the grid needs within my map's > > layout... > > > > > > > > -- Frederick > > > > > > > > On Fri, Dec 5, 2014 at 2:51 PM, Stefan Frey > > > <ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> > > > > <mailto:ste...@we... > > <mailto:ste...@we...> <mailto:ste...@we... > > <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>>>> wrote: > > > > > > > > Frederick: > > > > thanks for your feedback. > > > > I assumed this by the size of the files, > > however I > > > had no > > > time yet > > > > to look into details. > > > > > > > > One further question: What coordinates did you > > > choose for > > > your maps? > > > > Is it identical across your maps? What is the > > size > > > of one > > > hexagon in > > > > those coordinates. Have you already started > > to create > > > single tiles > > > > for reuse? I am keen on replacing the > > existing tile > > > creation process > > > > by a simpler one. > > > > > > > > Most likely you can guess where I am hinting > > at, but I > > > will give > > > > more details on Sunday. > > > > > > > > Great work, > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > > Frederick Weld <fre...@go... > > <mailto:fre...@go...> > > > <mailto:fre...@go... > > <mailto:fre...@go...>> > > > <mailto:fre...@go... > > <mailto:fre...@go...> > > > <mailto:fre...@go... > > <mailto:fre...@go...>>> > > > > <mailto:fre...@go... > > <mailto:fre...@go...> > > > <mailto:fre...@go... > > <mailto:fre...@go...>> > > > <mailto:fre...@go... > > <mailto:fre...@go...> > > > <mailto:fre...@go... > > <mailto:fre...@go...>>>>>schrieb: > > > > > > > > Stefan: > > > > I use Inkscape for creating/editing the > > vector maps. > > > They are > > > > stored in svg format. I couldn't imagine > > any other > > > combination > > > > which would fit our needs here in a > > better manner. > > > > > > > > SVG files are verbose but their size gets > > shrunk by > > > compression > > > > to 10-15% of the original size. My maps > are > > > <100k when > > > > compressed. Hence, I do not think this is > > a real > > > issue. > > > > > > > > However, the situation is different for > > converted > > > maps (in > > > > rails, e.g, 18EU, 18AL). They include a > > lot of > > > superfluous paths > > > > (including paths instead of text) and get > > > bloated and > > > slow to > > > > draw as a result. That (and copyright > > > considerations) > > > is why I > > > > always build my maps from the scratch. > > > > > > > > The svg lib could be exchanged, of > > course. But as a > > > > prerequisite, the new lib should be > > regression-free > > > with respect > > > > to exiting background maps. > > > > > > > > -- Frederick > > > > > > > > On Thu, Dec 4, 2014 at 12:14 PM, Stefan > > > Frey<ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> > > > > <mailto:ste...@we... > > <mailto:ste...@we...> > > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... > > <mailto:ste...@we...> <mailto:ste...@we... > > <mailto:ste...@we...>>>>> > > > wrote: > > > > > > > > Frederick: > > > > we could do that later on. Most > > people now > > > know that > > > > rails_2_develop is > > > > the (default) branch for rails 2. > > > > > > > > My (future) release strategy is based > on > > > > > > > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > > > > > However I still consider moving the > > git repo > > > (only the repo, > > > > not the > > > > other parts) to github, then this > > will happen > > > with the > > > > official rails > > > > 2.0 release. > > > > > > > > I am looking forward to seeing more > maps > > > from you. > > > > > > > > One question: In which format and > > tools do you > > > create your > > > > maps? > > > > > > > > Most likely you will know that I > > intend to > > > replace the Batik > > > > lib soon. > > > > However which long-run strategy to ch > > oose > > > how display > > > > maps/tiles for Rails. > > > > > > > > In the short-run I will simply > > replace Batik > > > by a > > > more > > > > light-weight SVG > > > > library, but I am open to > > recommendations. > > > > > > > > Stefan > > > > > > > > > > > > On 12/04/2014 10:16 AM, Frederick > > Weld wrote: > > > > > Stefan: > > > > > There is no standard 1830 map yet. > > I will > > > probably do > > > > that after the > > > > > Coalfield map has been reviewed > > (bgg) and > > > thoroughly > > > > play-tested. > > > > > > > > > > How about labeling rails_2_develop > > as master? > > > Then the > > > > meaning would be > > > > > clear: Current state of validated > > development > > > which is > > > > eligible for the > > > > > next release. > > > > > > > > > > -- Frederick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Download BIRT iHub F-Type - The > Free > > > Enterprise-Grade > > > > BIRT Server > > > > > from Actuate! Instantly > > Supercharge Your > > > Business Reports > > > > and Dashboards > > > > > with Interactivity, Sharing, > > Native Excel > > > Exports, App > > > > Integration & more > > > > > Get technology previously reserved > for > > > billion-dollar > > > > corporations, FREE > > > > > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Rails-devel mailing list > > > > >Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>>> > > > > > > > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > > Enterprise-Grade BIRT > > > > Server > > > > from Actuate! Instantly Supercharge > Your > > > Business > > > Reports > > > > and Dashboards > > > > with Interactivity, Sharing, Native > Excel > > > Exports, App > > > > Integration & more > > > > Get technology previously reserved for > > > billion-dollar > > > > corporations, FREE > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>>> > > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > > Enterprise-Grade > > > BIRT > > > > Server from Actuate! Instantly > > Supercharge Your > > > Business Reports > > > > and Dashboards with Interactivity, > Sharing, > > > Native Excel > > > > Exports, App Integration & more Get > > technology > > > previously > > > > reserved for billion-dollar corporations, > > > > > > > > > > > > FREEhttp:// > pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > > > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > > > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > > > > > > > > > > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > > Rails-devel mailing > > > lis...@li... > > <mailto:lis...@li...> > > > <mailto:lis...@li... > > <mailto:lis...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>>> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade > > > BIRT Server > > > > from Actuate! Instantly Supercharge Your > Business > > > Reports > > > and Dashboards > > > > with Interactivity, Sharing, Native Excel > > Exports, App > > > Integration & > > > > more > > > > Get technology previously reserved for > > billion-dollar > > > corporations, FREE > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > Enterprise-Grade > > > BIRT Server > > > > from Actuate! Instantly Supercharge Your Business > > > Reports and > > > Dashboards > > > > with Interactivity, Sharing, Native Excel Exports, > App > > > Integration & more > > > > Get technology previously reserved for > billion-dollar > > > corporations, FREE > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > >Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade BIRT > > > Server > > > from Actuate! Instantly Supercharge Your Business > > Reports and > > > Dashboards > > > with Interactivity, Sharing, Native Excel Exports, > App > > > Integration & more > > > Get technology previously reserved for billion-dollar > > > corporations, FREE > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade > > BIRT Server > > > from Actuate! Instantly Supercharge Your Business > > Reports and > > > Dashboards with Interactivity, Sharing, Native Excel > > Exports, App > > > Integration & more Get technology previously reserved for > > > billion-dollar corporations, > > > > > > > > FREEhttp:// > pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > > > < > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > > > > > Rails-devel mailing list > > > > > > Rai...@li...https:// > lists.sourceforge.net/lists/listinfo/rails-devel > > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT > Server > > > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > > with Interactivity, Sharing, Native Excel Exports, App > Integration & > > > more > > > Get technology previously reserved for billion-dollar > corporations, FREE > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > >Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > > with Interactivity, Sharing, Native Excel Exports, App Integration > & more > > > Get technology previously reserved for billion-dollar > > corporations, FREE > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & > > more > > Get technology previously reserved for billion-dollar corporations, > FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Stefan F. <ste...@we...> - 2014-12-09 15:57:36
|
Frederick: you also have very valid points: I will surely respect the freedom of the designer to add anything that is not dynamic. So everything that is now printed on a 18xx map (including the offboard values) can be defined by the designer. I do not want to interfere there. However two things I want to add: (1) Make it easier for the designer by getting a kind of "template" map using all information from the xml for consistency. It would also make things easier for designers to choose the correct scaling (especially they could paste and copy tiles from the rails repository or reuse parts of existing maps). (2) Do not require the designer to define all elements, which could be potentially created by Rails: E.g. coordinates, pre-painted tiles, tile costs, revenue values on specific tiles. Think e.g. variants like in 1856 where only the revenue value of Toronto is changed. Do we need an additional background map for this? Or the variant with alternative destinations etc. However it could be optional, thus it can be defined in the xml files, if those come from the map or a created by Rails. (3) We can keep the current background map option, which is basically a plain background image, with scaling and translation option which is a very loose coupling. The good thing is that Rails is very well adopted to live with many variations, thus the increased complexity can very well be handled. Stefan On 12/09/2014 03:57 PM, Frederick Weld wrote: > Stefan: > All these are valid points. I guess that this is all about the decision > into which direction rails should go with respect to the map: > > (1) Leave it as it is (loosely coupled, working with arbitrary svgs). An > option here is to add a tool for exporting arbitrary map/companyMgr xmls > as svg prototypes. > > (2) Establish a closer link between the map svg and the game. This means > that the map has to fulfill specific requirements like having a specific > coordinate system or omitting information which is drawn by the game > instead or even further requirements that lead to even tighter integration. > > As I said, option (1) would be ok for me. The tool would assist the > designer to some degree. > > Regarding option (2), I wouldn't like it that much. As an example, the > designer would also want to define the positioning/style of the offboard > values. Removing the aforementioned redundancy would only be possible if > the game/design integration was much tighter, eg., using text/value > place holders in the svg design. But then the map designer does not > control every aspect of the representation any more (he might want to > adjust the style depending on the text/value's length etc.). > > Currently, the only aspect which is according to (2) are the row/column > coordinates which I omitted from my svgs as a result. This is ok for me > as I seldom need them, but anything beyond would really be detrimental > from my point of view. > > As for the token svgs: I thought about that (incl. code to display them > instead of imperative token drawing) some years ago but I didn't move > forward with that. The reasoning behind this was as follows: Other parts > of the game (especially Game status window) have a textual-only > representation of the companies. Depending on the token art, it could be > difficult to match it to the company name. So either each and every part > of the UI gets these svg tokens or the tokens remain text based. > Personally, I'm quite happy with the current solution. > > -- Frederick > > > On Tue, Dec 9, 2014 at 11:50 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Frederick: > my goal is both to shorten time for the designer and make e.g. scaling > problems less an issue. > > Would you not think that the hex grid will already help other designers > to know how large the map size will be. So it is less an issue to scale > and translate which currently is far from perfect. > > Map.xml is not reliable, as it is hardly used so far. However it is not > that diffcult to get that up-to-date. However most likely it will not > add that automatically, as due to text scaling and positioning it is > better for a human to decide where and how to put it. > > But offboard values should better be derived from xml, as it avoids > double definition, which is really confusing for players (the same is > not true for city names which usually have no real impact in 18xx). > > And know I will not manipulate Tokens by code and I would only like to > place tokens on tiles by code. This requires tiles to adhere a specific > structure (to locate the token slots), not potential tokens svg files. > Would you be interested to design tokens for Rails in svg? It is easy to > add code to support user-supplied tokens, if anyone is interested to > create some. > > Stefan > > > On 12/09/2014 11:31 AM, Frederick Weld wrote: > > Stefan: > > If your goal is to shorten the time a designer needs for a new svg, > > these ideas would certainly contribute to that. Although, for me, > > recreating the hex grid amounted to only about 10% of the time, the > > remainder being creating coastlines/rivers and design/placing of shapes. > > > > Map.xml's city/town names are also not reliable - at least town names > > are never included. > > > > So, as a result, I wouldn't create more svgs if such svg pregeneration > > functionality existed. But on the other hand, it would save me some > > amount of time if I created one. > > > > For doing more with the svg (incorporating artful tokens etc.), I have > > my doubts about that. It would be too easy for a WYSIWYG editor to mess > > this up. Such svgs would have to be edited in an xml editor after the > > designer had completed his initial work... > > > > -- Frederick > > > > On Tue, Dec 9, 2014 at 11:09 AM, Stefan Frey <ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > Frederick, > > no I am realistic that a designer of a map cares more about > the SVG > > structure than you already did. I only wondered how far you > went, most > > likely you define the upper limit of carefulness. ;-) > > > > My goal is to separate those parts of the background map, > which are > > better generated/manipulated by > > the code and which by the human designer. > > > > My current thoughts are: > > > > * A hex grid SVG definition should be generated by a program. > There are > > SVG online generators (e.g. > > http://axiscity.hexamon.net/users/isomage/misc/svg-hex.cgi), > however I > > assume coding an own one, is not too difficult. This would > allow to > > generate a hexgrid as a SVG based on Rails map definitions. > > > > * The hex grid could then be imported by a designer to add the > > background map. If Inkscape is used it is easy to separate > the two parts > > (grid and map) by layers. > > > > * It is possible to add another SVG layer that shows the Rails > > predefined tiles on the hexgrid. This would make the > designing task > > easier, at it would show, what content is expected in each hex. > > By using layers, it can be easily separated later on. > > > > I still have to think more about tiles. I would like to > change tiles > > that it is possible to change them by code. This would imply > that the > > base structure has to be defined manually to make code > manipulation > > easier. The reason for that would be e.g. to add tokens, add > offboard > > values, city names, all stuff that is already contained in > the xml > > definitions. > > > > What do you (and others think) about that? > > > > Stefan > > > > > > Frederick Weld <fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>>schrieb: > > > > Stefan: > > Actually, I use Inkscape as a WYSIWYG tool and do not > bother about > > redundancies in the residual svg as long as the file > size is less > > than 100k. I keep the layers and grouping in the pushed svg > > versions > > so that anyone could easily alter aspects of the svg. > > > > A lot of your questions are pointing into the direction > that the > > designer needs to care more about the svg model. That > could come > > with a lot of advantages but keep in mind that any > compulsion to do > > this could potentially turn away WYSIWYG designers. Here > are some > > answers: > > > > - The ids are auto-assigned but could be changed within > the tool. > > > > - I don't think that Inkscape can be forced to retain > the syntax of > > tiles copied from outside. > > > > - I am not aware of any in-tool support for css, but I could > > imagine > > that other tools (or even Inkscape with direct svg > editing) provide > > for that. > > > > - I use separate hexes instead of a hex grid since I > often need the > > hex definition to add a filling (eg., prelaid tiles at > the coast). > > But I imagine that other designs could differ regarding this > > aspect. > > > > -- Frederick > > > > On Mon, Dec 8, 2014 at 6:09 PM, Stefan > Frey<ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>> wrote: > > > > Frederick: > > thanks a lot. Your feedback is really helpful. > > > > And I appreciate your functional but good-looking > design. > > > > I am currently looking into how interact with the > svg maps from > > inside > > the code. > > > > Maybe some questions up-front: > > > > * How did you (or Inkscape) assing ids to your > elements? Is > > there any > > system to it, that relates to the actual 18xx > definitions? > > > > * Is it possible to force Inkscape to use pre-defined > > styles for > > attributes (inline or external CSS) to reduce the > replication > > inside the > > svg? > > > > * Inkscape seems to change the syntax of tile > definitions > > at the > > time > > copying (e.g. uses relative coordinates instead of > absolute > > coordinates > > for the path definitions). > > > > * It seems that it is possible to save it as plain > svg without > > quality > > loss (however it prevents Inkscape to identify the layer > > information). > > > > * Do you have a good idea to avoid the duplication > of drawing > > the hex > > borders? I think it would be a good idea to separate > > drawing the hex > > grid from the hex content to avoid that. > > > > I do not want to change the map code too much in 2.0, > > except for > > replacing batik. However I want to improve that in > the next > > upcoming > > releases. So I am still very open for ideas. > > > > Stefan > > > > > > On 12/05/2014 03:12 PM, Frederick Weld wrote: > > > Stefan: > > > The hexes have the same size as the tile svgs. > This makes it > > possible to > > > just copy required tiles (Altoona...) from the > tile svg into > > the map. > > > > > > These tile svgs are the one very important > element of reuse. > > > > > > I reuse further parts from my former maps - but > this is > > rather pure > > > design (shape/color patterns for rendering...). > > > > > > I do not use any specific coordinate system and, as a > > result, > > I have to > > > calibrate the maps within the game to get the > x/y/scale > > parameters. This > > > is no drawback though, as I often want to be able to > > make the > > decision > > > how much "padding" the grid needs within my map's > layout... > > > > > > -- Frederick > > > > > > On Fri, Dec 5, 2014 at 2:51 PM, Stefan Frey > > <ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... > <mailto:ste...@we...> <mailto:ste...@we... > <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>>> wrote: > > > > > > Frederick: > > > thanks for your feedback. > > > I assumed this by the size of the files, > however I > > had no > > time yet > > > to look into details. > > > > > > One further question: What coordinates did you > > choose for > > your maps? > > > Is it identical across your maps? What is the > size > > of one > > hexagon in > > > those coordinates. Have you already started > to create > > single tiles > > > for reuse? I am keen on replacing the > existing tile > > creation process > > > by a simpler one. > > > > > > Most likely you can guess where I am hinting > at, but I > > will give > > > more details on Sunday. > > > > > > Great work, > > > Stefan > > > > > > > > > > > > > > > > > > Frederick Weld <fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>> > > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>> > > <mailto:fre...@go... > <mailto:fre...@go...> > > <mailto:fre...@go... > <mailto:fre...@go...>>>>>schrieb: > > > > > > Stefan: > > > I use Inkscape for creating/editing the > vector maps. > > They are > > > stored in svg format. I couldn't imagine > any other > > combination > > > which would fit our needs here in a > better manner. > > > > > > SVG files are verbose but their size gets > shrunk by > > compression > > > to 10-15% of the original size. My maps are > > <100k when > > > compressed. Hence, I do not think this is > a real > > issue. > > > > > > However, the situation is different for > converted > > maps (in > > > rails, e.g, 18EU, 18AL). They include a > lot of > > superfluous paths > > > (including paths instead of text) and get > > bloated and > > slow to > > > draw as a result. That (and copyright > > considerations) > > is why I > > > always build my maps from the scratch. > > > > > > The svg lib could be exchanged, of > course. But as a > > > prerequisite, the new lib should be > regression-free > > with respect > > > to exiting background maps. > > > > > > -- Frederick > > > > > > On Thu, Dec 4, 2014 at 12:14 PM, Stefan > > Frey<ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>> > > > <mailto:ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > <mailto:ste...@we... > <mailto:ste...@we...> <mailto:ste...@we... > <mailto:ste...@we...>>>>> > > wrote: > > > > > > Frederick: > > > we could do that later on. Most > people now > > know that > > > rails_2_develop is > > > the (default) branch for rails 2. > > > > > > My (future) release strategy is based on > > > > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > > > However I still consider moving the > git repo > > (only the repo, > > > not the > > > other parts) to github, then this > will happen > > with the > > > official rails > > > 2.0 release. > > > > > > I am looking forward to seeing more maps > > from you. > > > > > > One question: In which format and > tools do you > > create your > > > maps? > > > > > > Most likely you will know that I > intend to > > replace the Batik > > > lib soon. > > > However which long-run strategy to ch > oose > > how display > > > maps/tiles for Rails. > > > > > > In the short-run I will simply > replace Batik > > by a > > more > > > light-weight SVG > > > library, but I am open to > recommendations. > > > > > > Stefan > > > > > > > > > On 12/04/2014 10:16 AM, Frederick > Weld wrote: > > > > Stefan: > > > > There is no standard 1830 map yet. > I will > > probably do > > > that after the > > > > Coalfield map has been reviewed > (bgg) and > > thoroughly > > > play-tested. > > > > > > > > How about labeling rails_2_develop > as master? > > Then the > > > meaning would be > > > > clear: Current state of validated > development > > which is > > > eligible for the > > > > next release. > > > > > > > > -- Frederick > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade > > > BIRT Server > > > > from Actuate! Instantly > Supercharge Your > > Business Reports > > > and Dashboards > > > > with Interactivity, Sharing, > Native Excel > > Exports, App > > > Integration & more > > > > Get technology previously reserved for > > billion-dollar > > > corporations, FREE > > > > > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade BIRT > > > Server > > > from Actuate! Instantly Supercharge Your > > Business > > Reports > > > and Dashboards > > > with Interactivity, Sharing, Native Excel > > Exports, App > > > Integration & more > > > Get technology previously reserved for > > billion-dollar > > > corporations, FREE > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free > > Enterprise-Grade > > BIRT > > > Server from Actuate! Instantly > Supercharge Your > > Business Reports > > > and Dashboards with Interactivity, Sharing, > > Native Excel > > > Exports, App Integration & more Get > technology > > previously > > > reserved for billion-dollar corporations, > > > > > > > > FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > > > > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > Rails-devel mailing > > lis...@li... > <mailto:lis...@li...> > > <mailto:lis...@li... > <mailto:lis...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>>https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free > Enterprise-Grade > > BIRT Server > > > from Actuate! Instantly Supercharge Your Business > > Reports > > and Dashboards > > > with Interactivity, Sharing, Native Excel > Exports, App > > Integration & > > > more > > > Get technology previously reserved for > billion-dollar > > corporations, FREE > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Download BIRT iHub F-Type - The Free Enterprise-Grade > > BIRT Server > > > from Actuate! Instantly Supercharge Your Business > > Reports and > > Dashboards > > > with Interactivity, Sharing, Native Excel Exports, App > > Integration & more > > > Get technology previously reserved for billion-dollar > > corporations, FREE > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free > Enterprise-Grade BIRT > > Server > > from Actuate! Instantly Supercharge Your Business > Reports and > > Dashboards > > with Interactivity, Sharing, Native Excel Exports, App > > Integration & more > > Get technology previously reserved for billion-dollar > > corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade > BIRT Server > > from Actuate! Instantly Supercharge Your Business > Reports and > > Dashboards with Interactivity, Sharing, Native Excel > Exports, App > > Integration & more Get technology previously reserved for > > billion-dollar corporations, > > > > > FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > > <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________> > > Rails-devel mailing list > > > > Rai...@li...https://lists.sourceforge.net/lists/listinfo/rails-devel > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > <http://lists.sourceforge.net/lists/listinfo/rails-devel> > > <https://lists.sourceforge.net/lists/listinfo/rails-devel> > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & > > more > > Get technology previously reserved for billion-dollar corporations, FREE > >http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > >Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar > corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & > more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |