From: brett l. <bre...@gm...> - 2010-05-31 14:28:08
|
I'm pleased to announce that Rails 1.3 is now available. This release adds an initial implementation of automated route and revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in this release is revised documentation on how well-supported each game is. Download the new release at http://rails.sourceforge.net/ ---Brett. |
From: Jeff F. <fe...@op...> - 2010-05-31 14:45:58
|
I just loaded up an 1830 save file in which I ended the previous OR by exchanging a 4 train for a D. When I make the move and save the file (using either Rails 1.2.2 or Rails 1.3), Rails 1.3 says it's an illegal move and rewinds the game back to the buy train step. It's definitely legal, and Rails 1.3 lets me do it, but it won't let me load up a save containing the move. Jeff brett lentz wrote: > I'm pleased to announce that Rails 1.3 is now available. > > This release adds an initial implementation of automated route and > revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in > this release is revised documentation on how well-supported each game > is. > > Download the new release at http://rails.sourceforge.net/ > > ---Brett. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Rails-announce mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-announce > > > |
From: Stefan F. <ste...@we...> - 2010-05-31 20:00:14
|
To avoid some disappointment with this release I will give some more hints what to expect. There has been some bug-fixes which can cause some save files to be incompatible with the new release. Exchange of trains is one example. If such an error occurs either stay with the previous release or start at that point and replay the missing moves. Another thing to mention is that route and revenue calculation is disabled by default for save files from previous Rails version. This allows pbem users to update to that rails version for bug-fixes who do want to play with automatic game support turned on. For new games the default is to activate them, but each of them can be deactivated under the game options. And to finish here is that Erik has improved 1835 that it is ready for serious testing, but please do not start long-running pbems yet ;-) Stefan On Monday 31 May 2010 16:45:46 Jeff Feuer wrote: > I just loaded up an 1830 save file in which I ended the previous OR by > exchanging a 4 train for a D. When I make the move and save the file > (using either Rails 1.2.2 or Rails 1.3), Rails 1.3 says it's an illegal > move and rewinds the game back to the buy train step. It's definitely > legal, and Rails 1.3 lets me do it, but it won't let me load up a save > containing the move. > > Jeff > > brett lentz wrote: > > I'm pleased to announce that Rails 1.3 is now available. > > > > This release adds an initial implementation of automated route and > > revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in > > this release is revised documentation on how well-supported each game > > is. > > > > Download the new release at http://rails.sourceforge.net/ > > > > ---Brett. > > > > ------------------------------------------------------------------------- > >----- > > > > _______________________________________________ > > Rails-announce mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-announce > > --------------------------------------------------------------------------- >--- > > _______________________________________________ > Rails-users mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-users |
From: brett l. <bre...@gm...> - 2010-06-03 16:49:35
|
On Mon, May 31, 2010 at 7:27 AM, brett lentz <bre...@gm...> wrote: > I'm pleased to announce that Rails 1.3 is now available. > > This release adds an initial implementation of automated route and > revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in > this release is revised documentation on how well-supported each game > is. > > Download the new release at http://rails.sourceforge.net/ > > ---Brett. > Apologies all around. An issue with my e-mail prevented me from sending out a proper changelog with my announcement. So, here is the changelog for 1.3: * Tile and Token Laying - Hexes which are eligible for tile and token lays are highlighted - Only a game hint, not enforced. * Revenue Calculation - Maximum revenue for the owned trains is suggested - Presetting for the revenue entry, has still to be confirmed or can be adjusted - Should incorporate all game specific rules, including bonus rules * Map Correction - Downgrade of tiles is now possible - Only tile availability is checked, otherwise no restrictions are applied - Tile lays that require the re-laying out of tokens are not possible * General - Prevent 'foreign' token being layed on reserved home token slots. - Fixed bugs in OO-tile and token laying. - Fixed occasional incorrect priority deal assignment after 1830-style auctions. - Fixed disappearance of last (highest) train bought. - Added option to fix tile orientation (used for 1835 Hamburg). * 1830 - Fixed possibility of buying a Diesel at exchange price without an exchange taking place. * 1835 - Finished/Fixed Prussian formation - Allow 100% share ownership and nationalization. - Bugs in initial round player order (Clemens variant) and BY flotation. - Added several variant options. * 1856 - (also for 18EU) added (invisible) City object to Goderich/Hamburg tile to facilitate revenue calculation. - Fixed bug in effect of repeated 5% CGR share sales on share price. - Fixed W&S token lay cost problem. * 18EU - Fixes for bankruptcy rules (not yet tested under all possible circumstances). |
From: Stefan F. (web.de) <ste...@we...> - 2010-06-08 21:24:15
|
Two bugs in 1.3: -> Serious, but easy to fix (already done in CVS): 18Kaas had the name of the new game option wrongly defined, that prevented any start/load of a 18Kaas game. Seems to be not a very popular choice, as no one complained so far... -> Very minor, but a difficult one: The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is not complete: Currently only the malus is only applied if the train runs through Hamburg and crosses the Elbe. There is a second part that is not yet implemented: If a train starts from a base token in Hamburg it is important if that base token lays south (Harburg) or north (City or Altona) the river Elbe. This is not possible to implement so far, as the current tile definition does not distinguish between the north/south slots on the brown Hamburg tile. I do not know if we should really go all the way to get that implemented, the current workaround is to reduce the revenue suggested by 10 if that situation occurs (unless one finds an alternative run with identical revenue that does not start on other side of the river). Stefan On Monday 31 May 2010 16:27:38 brett lentz wrote: > I'm pleased to announce that Rails 1.3 is now available. > > This release adds an initial implementation of automated route and > revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in > this release is revised documentation on how well-supported each game > is. > > Download the new release at http://rails.sourceforge.net/ > > ---Brett. > > --------------------------------------------------------------------------- >--- > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Phil D. <de...@gm...> - 2010-06-08 22:36:14
|
We don't currently have the tile for Hamburg that shows the difference either, I'd sort of argue that this is such a niche rule it's almost not worth taking the effort over. Unless of course there are games with equally similar tiles that would benefit from this differentiation Phil On 8 June 2010 22:23, Stefan Frey (web.de) <ste...@we...> wrote: > Two bugs in 1.3: > -> Serious, but easy to fix (already done in CVS): > 18Kaas had the name of the new game option wrongly defined, that prevented any > start/load of a 18Kaas game. Seems to be not a very popular choice, as no one > complained so far... > > -> Very minor, but a difficult one: > The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is > not complete: Currently only the malus is only applied if the train runs > through Hamburg and crosses the Elbe. There is a second part that is not yet > implemented: If a train starts from a base token in Hamburg it is important > if that base token lays south (Harburg) or north (City or Altona) the river > Elbe. This is not possible to implement so far, as the current tile > definition does not distinguish between the north/south slots on the brown > Hamburg tile. I do not know if we should really go all the way to get that > implemented, the current workaround is to reduce the revenue suggested by 10 > if that situation occurs (unless one finds an alternative run with identical > revenue that does not start on other side of the river). > > Stefan > > > On Monday 31 May 2010 16:27:38 brett lentz wrote: >> I'm pleased to announce that Rails 1.3 is now available. >> >> This release adds an initial implementation of automated route and >> revenue calculation as well as bug fixes for 1830, 1856, 1889. Also in >> this release is revised documentation on how well-supported each game >> is. >> >> Download the new release at http://rails.sourceforge.net/ >> >> ---Brett. >> >> --------------------------------------------------------------------------- >>--- >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: John D. G. <jd...@di...> - 2010-06-11 03:44:57
|
Stefan Frey (web.de) wrote: > -> Very minor, but a difficult one: > The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is > not complete: Currently only the malus is only applied if the train runs > through Hamburg and crosses the Elbe. There is a second part that is not yet > implemented: If a train starts from a base token in Hamburg it is important > if that base token lays south (Harburg) or north (City or Altona) the river > Elbe. If that is the prevailing view in Germany, then it ought to be brought up for discussion on the 18xx list. Because every group I've played 1835 with in the US and Canada plays that it never matters which side of the Elbe your token is on: if Hamburg is the beginning or end of your route, you don't suffer the penalty. |
From: Phil D. <de...@gm...> - 2010-06-11 08:57:43
|
The tile encyclopaedia does point this out as a source of contention amongst players: http://www.18xx.net/tiles/e221.htm ' (It is unclear, and a source of argument, whether this reduction applies to a run that begins or ends in Hamburg. If the answer is yes, then it makes a difference which side of the river your company's station marker is on. If the answer is no, it does not make any difference.)' I've not played the physical game but the rules reading would imply that if for any reason your train cross that central 'ferry' symbol representing the river then Hamburg is 10 less. For a route terminating in Hamburg this is irrelevant since you can always terminate at another corps station, but for starting out it would be important where your token was placed. On 11 June 2010 05:43, John David Galt <jd...@di...> wrote: > Stefan Frey (web.de) wrote: >> -> Very minor, but a difficult one: >> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is >> not complete: Currently only the malus is only applied if the train runs >> through Hamburg and crosses the Elbe. There is a second part that is not yet >> implemented: If a train starts from a base token in Hamburg it is important >> if that base token lays south (Harburg) or north (City or Altona) the river >> Elbe. > > If that is the prevailing view in Germany, then it ought to be brought up for > discussion on the 18xx list. Because every group I've played 1835 with in the > US and Canada plays that it never matters which side of the Elbe your token is > on: if Hamburg is the beginning or end of your route, you don't suffer the > penalty. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Chris S. <chr...@gm...> - 2010-06-14 14:37:01
|
Actually, for a route terminating in Hamburg, the relevant question would be "does the route intersect one of your own tokens elsewhere?" If yes, you can terminate in any Hamburg city circle. If the only owner station token on the route is in Hamburg, then it would matter which side of the river it was on and which path was taken to reach it. -- Chris Please consider the environment before printing this e-mail. On Fri, Jun 11, 2010 at 1:57 AM, Phil Davies <de...@gm...> wrote: > The tile encyclopaedia does point this out as a source of contention > amongst players: > > http://www.18xx.net/tiles/e221.htm > > ' (It is unclear, and a source of argument, whether this reduction > applies to a run that begins or ends in Hamburg. If the answer is > yes, then it makes a difference which side of the river your company's > station marker is on. If the answer is no, it does not make any > difference.)' > > I've not played the physical game but the rules reading would imply > that if for any reason your train cross that central 'ferry' symbol > representing the river then Hamburg is 10 less. For a route > terminating in Hamburg this is irrelevant since you can always > terminate at another corps station, but for starting out it would be > important where your token was placed. > > On 11 June 2010 05:43, John David Galt <jd...@di...> > wrote: > > Stefan Frey (web.de) wrote: > >> -> Very minor, but a difficult one: > >> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in > Hamburg is > >> not complete: Currently only the malus is only applied if the train runs > >> through Hamburg and crosses the Elbe. There is a second part that is > not yet > >> implemented: If a train starts from a base token in Hamburg it is > important > >> if that base token lays south (Harburg) or north (City or Altona) the > river > >> Elbe. > > > > If that is the prevailing view in Germany, then it ought to be brought up > for > > discussion on the 18xx list. Because every group I've played 1835 with > in the > > US and Canada plays that it never matters which side of the Elbe your > token is > > on: if Hamburg is the beginning or end of your route, you don't suffer > the > > penalty. > > > > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: John D. G. <jd...@di...> - 2010-06-15 03:26:41
|
Chris Shaffer wrote: > Actually, for a route terminating in Hamburg, the relevant question > would be "does the route intersect one of your own tokens elsewhere?" > If yes, you can terminate in any Hamburg city circle. If the only owner > station token on the route is in Hamburg, then it would matter which > side of the river it was on and which path was taken to reach it. Good point. I'll edit that page on 18xx.net. :) |
From: John D. G. <jd...@di...> - 2010-06-13 16:04:14
|
I tried a 4 player game last night. The initial round went as expected, though it was annoying that we were compelled to float the By to allow the game to continue (if this were not forced, the OB would have been left unpurchased for one round because the only one who could afford it was the LD/Sx owner. This is usual for us). The map error near Dusseldorf/Essen is fixed now. The logic to limit which hexes you can lay tiles in seems correct -- except that (1) it still offers to let the Pfalz owner place Mannheim during yellow phase, and (2) it doesn't let you start the game by dropping a token in Nurnberg and then build track north from there on turn 1 (which some of us believe is legal). But while that logic "knows" about route connections, the tile rotation logic doesn't. That is, you're still allowed (and sometimes offered as first choice) the ability to place a new tile rotated so that it doesn't connect to your route. Also, the controls to place a tile seem annoyingly finicky -- you have to click directly on the image of the tile you want to place, even though its description takes up a larger space that looks like a button. The route calculation logic seems correct when it gives an answer at all. But in most turns it did not even guess at a revenue number for By. I ran into a real show stopper, though, in the stock round when Ba formed. I backed up (undid) a couple of turns to test "what ifs". Then I found out the hard way that when you undo the purchase of a Ba share, the share seems to get put back on the bottom of the stack! (That is, after two players together bought 60% of Ba, undid two 10% purchases, and redid them, I can't buy the seventh share -- it insists the next share I buy be 20%!) At this point I quit. I also tried out the "Cash Correction" mode just to see if it would help, and found that once you select it you can't cancel it without changing anything. Entering zero gets you an error popup. |
From: Phil D. <de...@gm...> - 2010-06-13 19:05:05
|
On 13 Jun 2010, at 18:01, John David Galt <jd...@di...> wrote: > I tried a 4 player game last night. > > The initial round went as expected, though it was annoying that we > were > compelled to float the By to allow the game to continue (if this > were not > forced, the OB would have been left unpurchased for one round > because the > only one who could afford it was the LD/Sx owner. This is usual for > us). > > The map error near Dusseldorf/Essen is fixed now. > > The logic to limit which hexes you can lay tiles in seems correct -- > except > that (1) it still offers to let the Pfalz owner place Mannheim during > yellow phase, and (2) it doesn't let you start the game by dropping > a token > in Nurnberg and then build track north from there on turn 1 (which > some of > us believe is legal). > > But while that logic "knows" about route connections, the tile > rotation > logic doesn't. That is, you're still allowed (and sometimes offered > as > first choice) the ability to place a new tile rotated so that it > doesn't > connect to your route. > > Also, the controls to place a tile seem annoyingly finicky -- you > have to > click directly on the image of the tile you want to place, even > though its > description takes up a larger space that looks like a button. > The route calculation logic seems correct when it gives an answer at > all. > But in most turns it did not even guess at a revenue number for By. > > I ran into a real show stopper, though, in the stock round when Ba > formed. > I backed up (undid) a couple of turns to test "what ifs". Then I > found out > the hard way that when you undo the purchase of a Ba share, the > share seems > to get put back on the bottom of the stack! (That is, after two > players > together bought 60% of Ba, undid two 10% purchases, and redid them, > I can't > buy the seventh share -- it insists the next share I buy be 20%!) > This behaviour has already been logged as a bug, the stack order for IPO purchases can get strangely broken in certain scenarios. > At this point I quit. > > I also tried out the "Cash Correction" mode just to see if it would > help, > and found that once you select it you can't cancel it without changing > anything. Entering zero gets you an error popup. > You leave cash correction by selecting 'leave cash correction' under the moderator menu. There would never be a reason to enter a 0 cash correction. Phil > --- > --- > --- > --------------------------------------------------------------------- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Stefan F. (web.de) <ste...@we...> - 2010-06-17 22:37:28
|
Hi John, thanks a lot for the detailed report. Most issues were already addressed, but I would still like to add some details for the parts I am responsible. > But while that logic "knows" about route connections, the tile rotation > logic doesn't. That is, you're still allowed (and sometimes offered as > first choice) the ability to place a new tile rotated so that it doesn't > connect to your route. You are right with your complain, the (current) highlighting only indicates the hexes were the route network has open ends. The rule enforcing for tile laying in Rails has not changed (yet). Enforcement is on my list, but it requires a more drastic change of the current UI implementation. It will also consider the various approaches (permissive, restrictive, semi-restrictive), with the default set accordingly for each game. > > Also, the controls to place a tile seem annoyingly finicky -- you have to > click directly on the image of the tile you want to place, even though its > description takes up a larger space that looks like a button. The controls are those in the panel on the left to the map to select the tiles? On my system it is sufficient to click on the description and it neither takes up a larger space than the tile. But I have a linux system, so my observation does not imply a lot. > > The route calculation logic seems correct when it gives an answer at all. > But in most turns it did not even guess at a revenue number for By. Most likely the graph generator or the revenue calculator ran into bug. It would be great, if you could share your save file to fix that, as for my own test cases no (such) bug occurs anymore. > > I also tried out the "Cash Correction" mode just to see if it would help, > and found that once you select it you can't cancel it without changing > anything. Entering zero gets you an error popup. I admit that I deliberately decided to block the usual game actions as long as (any) correction mode is active. My intention was to highlight that the actions available during correction allows the violation of game rules. And I admit that I have not considered what happens if someone does not figure out how to leave that mode. Maybe there should be some status bar, that indicates that you can leave the correction modes by deactivating them in the menu. The error popup on zero cash change is the standard implementation in Rails, if you select a non-valid parameter, as those checks are done by the backend. Sorry for trapping the game by this. Stefan |
From: Erik V. <eri...@xs...> - 2010-06-19 10:10:03
|
Some comments inserted below. Erik. -----Original Message----- From: Stefan Frey (web.de) [mailto:ste...@we...] Sent: Friday 18 June 2010 00:37 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3 Hi John, thanks a lot for the detailed report. Most issues were already addressed, but I would still like to add some details for the parts I am responsible. > But while that logic "knows" about route connections, the tile rotation > logic doesn't. That is, you're still allowed (and sometimes offered as > first choice) the ability to place a new tile rotated so that it doesn't > connect to your route. You are right with your complain, the (current) highlighting only indicates the hexes were the route network has open ends. The rule enforcing for tile laying in Rails has not changed (yet). Enforcement is on my list, but it requires a more drastic change of the current UI implementation. It will also consider the various approaches (permissive, restrictive, semi-restrictive), with the default set accordingly for each game. [EV] A permissive check would be easy to add. All that's needed is adding a call to a method that returns if a given track on a given hexside is part of a route (to be inserted in GUITile around line 115). The other approaches would require some more coding but need the same method call. > > Also, the controls to place a tile seem annoyingly finicky -- you have to > click directly on the image of the tile you want to place, even though its > description takes up a larger space that looks like a button. The controls are those in the panel on the left to the map to select the tiles? On my system it is sufficient to click on the description and it neither takes up a larger space than the tile. But I have a linux system, so my observation does not imply a lot. [EV] I'm on (or under) Windows, but I don't have any such problem either. BTW I find the current tile description somewhat confusing. Someone (Stefan?) has added the number of remaining tiles, which is good, but the # sign in front of that is more commonly used to prefix the tile number, as it is done in the Remaining Tiles panel. I would have put the number of tiles in parentheses, as is also done to indicate the number of remaining trains. > I also tried out the "Cash Correction" mode just to see if it would help, > and found that once you select it you can't cancel it without changing > anything. Entering zero gets you an error popup. I admit that I deliberately decided to block the usual game actions as long as (any) correction mode is active. My intention was to highlight that the actions available during correction allows the violation of game rules. And I admit that I have not considered what happens if someone does not figure out how to leave that mode. Maybe there should be some status bar, that indicates that you can leave the correction modes by deactivating them in the menu. The error popup on zero cash change is the standard implementation in Rails, if you select a non-valid parameter, as those checks are done by the backend. Sorry for trapping the game by this. [EV] Accepting 0 as a no-op should easily fix that. |
From: Stefan F. <ste...@we...> - 2010-06-20 12:40:46
|
Erik: to continue the discussion, see my comments / questions: > The rule enforcing for tile laying in Rails has not changed (yet). > Enforcement is on my list, but it requires a more drastic change of the > current UI implementation. It will also consider the various approaches > (permissive, restrictive, semi-restrictive), with the default set > accordingly > for each game. > > [EV] A permissive check would be easy to add. All that's needed is adding a > call to a method that returns if a given track on a given hexside is part > of a route (to be inserted in GUITile around line 115). The other > approaches would require some more coding but need the same method call. What currently stops me somehow from implementing it there is the more general question, if those validity checks should be part of the UI-code or better handled by the backend? Most likely for the current implementation it does not matter, but in the longer run (at least for my understanding) the backend should provide the information about valid tile lays for the UI. This information should be passed to the UI via the action objects? I have not searched the archive of the development for the issue of client/server separation exactly, so I do not know, what your planning there, but I would have guessed, that you prefer to have as much in the backend as possible. But you are right: I can add a method to the algorithm package, which checks if a tile can be laid in any valid orientation on a specified hex, given the current network structure. Then this could be used either by the backend or the GUI to check the validitity. The only thing that might be different is the way to pass the handle to the networkgraph instance. > > > [EV] I'm on (or under) Windows, but I don't have any such problem either. > BTW I find the current tile description somewhat confusing. Someone > (Stefan?) has added the number of remaining tiles, which is good, but the # > sign in front of that is more commonly used to prefix the tile number, as > it is done in the Remaining Tiles panel. I would have put the number of > tiles in parentheses, as is also done to indicate the number of remaining > trains. > That was me, it was first used only for the panel with the correction mode activated (to test the constraints). But players complained, that they would like to have that in the standard panel as well, I merged the code there. And I remembered the usage of "#", but thought that would imply the number of remaining tiles , instead of the tile number (may be a Math deformation). Can be easily changed to parentheses. > The error popup on zero cash change is the standard implementation in > Rails, > > if you select a non-valid parameter, as those checks are done by the > backend. > Sorry for trapping the game by this. > > [EV] Accepting 0 as a no-op should easily fix that. > You mean that a zero entered should leave the correction mode? This is difficult as the deactivation of the correction mode uses a different action, than the cash correction itself. But I could capture it by the UI already with a different message (for example, that you have to use the menu to deactivate), that is true. Stefan |
From: Erik V. <eri...@xs...> - 2010-06-25 13:16:29
|
See below. -----Original Message----- From: Stefan Frey [mailto:ste...@we...] Sent: Sunday 20 June 2010 14:41 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3 Erik: to continue the discussion, see my comments / questions: > The rule enforcing for tile laying in Rails has not changed (yet). > Enforcement is on my list, but it requires a more drastic change of the > current UI implementation. It will also consider the various approaches > (permissive, restrictive, semi-restrictive), with the default set > accordingly > for each game. > > [EV] A permissive check would be easy to add. All that's needed is adding a > call to a method that returns if a given track on a given hexside is part > of a route (to be inserted in GUITile around line 115). The other > approaches would require some more coding but need the same method call. What currently stops me somehow from implementing it there is the more general question, if those validity checks should be part of the UI-code or better handled by the backend? Most likely for the current implementation it does not matter, but in the longer run (at least for my understanding) the backend should provide the information about valid tile lays for the UI. This information should be passed to the UI via the action objects? I have not searched the archive of the development for the issue of client/server separation exactly, so I do not know, what your planning there, but I would have guessed, that you prefer to have as much in the backend as possible. [EV] Yes, in principle you are right on the client/server task division. But in this case, it would mean that the server would need to send to the client a full list of all tiles in all valid orientation that can be laid in any layable hex. Although that would be the right thing to do in theory, it would overload the client/server communication a bit, to my taste. LayTile is already prepared to carry a list of layable hexes. My preference would be to use only such a list, and leave sorting out the valid tiles and orientations to the UI. Most of that is based on the current map and the static tile upgrade specifications (any static info is always available to the UI). Then the only missing info in the client is about any allowed lays in unreachable hexes (already passed in special LayTile actions) and any reachable but disallowed hexes (partly covered in special code, partly yet uncovered, I think). Starting to use that list of layable hexes might fix the latter hole. However, this might imply that route evaluation should finally be done both (and separately) in the server and the client. IMO the server should be able to do a full validation of everything it gets from the clients (even if we only partially implement such validation). But I'm not sure how you think about that.... Erik. |
From: Stefan F. (web.de) <ste...@we...> - 2010-06-25 21:04:59
|
Erik: I have some doubts that splitting the support of the tile lay between the UI and the server is optimal. Especially if both have to do route calculations. To allow lightweight clients in the long run (think a browser), that part should be server only. I think there are two alternative options to consider: A) Are you really convinced that the message size for a complete list of possible tile lays and orientations is excessive? Assume that you have 20 hexes with 6 tiles each to replace. That is 120 combinations and each hex and tile can be identified by 2 bytes. A bitset for the 6 orientations would be another 1 byte. Thus overall a 600 bytes message. Even ten times larger should work. B) The client could ask the sequentially about the available options: First the server supplies a list of hexes, the UI selects the hex, the server response with available tiles, after tile selection, possible orientations are transmitted. I used this approach of partially completed actions for the map correction action, however for a different reason. Between the two approaches I am personally indifferent, B) is somehow more complex to implement, but has the advantage that all logic stays in the backend. From a network point of view solution A) is preferred, if the restricting factor is latency, B) to solve bandwidth issues. Stefan On Friday 25 June 2010 15:16:25 Erik Vos wrote: > [EV] Yes, in principle you are right on the client/server task division. > But in this case, it would mean that the server would need to send to the > client a full list of all tiles in all valid orientation that can be laid > in any layable hex. Although that would be the right thing to do in theory, > it would overload the client/server communication a bit, to my taste. > > LayTile is already prepared to carry a list of layable hexes. My preference > would be to use only such a list, and leave sorting out the valid tiles and > orientations to the UI. Most of that is based on the current map and the > static tile upgrade specifications (any static info is always available to > the UI). Then the only missing info in the client is about any allowed lays > in unreachable hexes (already passed in special LayTile actions) and any > reachable but disallowed hexes (partly covered in special code, partly yet > uncovered, I think). Starting to use that list of layable hexes might fix > the latter hole. > > However, this might imply that route evaluation should finally be done both > (and separately) in the server and the client. IMO the server should be > able to do a full validation of everything it gets from the clients (even > if we only partially implement such validation). But I'm not sure how you > think about that.... > > Erik. |
From: Erik V. <eri...@xs...> - 2010-06-26 11:55:33
|
Stefan, A third option could be: C) In addition to the "simple" LayTile of my proposal (only listing reachable hexes), send the current routes in some form or shape from server to client, and let the UI use these routes to sort out all laying restrictions. I don't know if sending route information is practical, though. About your options: A) In practice, I suppose it would be a (uuencoded serialized) List of Lists of something. Not sure what space that would take. Basically you're right that size would't be excessive. Just two additional remarks: - in my experience, it always pays off to keep traffic small, - don't forget that there will be a lot more stuff to transport from server to client. To name the probably biggest thing: all Observer updates. B) Partial actions I have been weeding out consistently since the early days, but I understand we now have them back already... (Yes, I remember we have had some discussions about that in the past). One drawback would be that more state needs be maintained (I suppose that's what you refer to as complexity). Another reason I'm somewhat concerned about this approach is that it might pose restrictions on further developments. One use case I have in mind is a future PBEM version. Will the users have stand-alone clients, exchanging messages over a slow channel, or will they all have full-blown Rails versions, sending mails to each other and/or to some central moderator? Most likely it'll be the latter, and then my concern is moot, but I'm not sure. Perhaps is just a matter of intuition. Facing a choice, my current order of preference would be A, C, B. Erik. -----Original Message----- From: Stefan Frey (web.de) [mailto:ste...@we...] Sent: Friday 25 June 2010 23:05 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3 Erik: I have some doubts that splitting the support of the tile lay between the UI and the server is optimal. Especially if both have to do route calculations. To allow lightweight clients in the long run (think a browser), that part should be server only. I think there are two alternative options to consider: A) Are you really convinced that the message size for a complete list of possible tile lays and orientations is excessive? Assume that you have 20 hexes with 6 tiles each to replace. That is 120 combinations and each hex and tile can be identified by 2 bytes. A bitset for the 6 orientations would be another 1 byte. Thus overall a 600 bytes message. Even ten times larger should work. B) The client could ask the sequentially about the available options: First the server supplies a list of hexes, the UI selects the hex, the server response with available tiles, after tile selection, possible orientations are transmitted. I used this approach of partially completed actions for the map correction action, however for a different reason. Between the two approaches I am personally indifferent, B) is somehow more complex to implement, but has the advantage that all logic stays in the backend. >From a network point of view solution A) is preferred, if the restricting factor is latency, B) to solve bandwidth issues. Stefan On Friday 25 June 2010 15:16:25 Erik Vos wrote: > [EV] Yes, in principle you are right on the client/server task division. > But in this case, it would mean that the server would need to send to the > client a full list of all tiles in all valid orientation that can be laid > in any layable hex. Although that would be the right thing to do in theory, > it would overload the client/server communication a bit, to my taste. > > LayTile is already prepared to carry a list of layable hexes. My preference > would be to use only such a list, and leave sorting out the valid tiles and > orientations to the UI. Most of that is based on the current map and the > static tile upgrade specifications (any static info is always available to > the UI). Then the only missing info in the client is about any allowed lays > in unreachable hexes (already passed in special LayTile actions) and any > reachable but disallowed hexes (partly covered in special code, partly yet > uncovered, I think). Starting to use that list of layable hexes might fix > the latter hole. > > However, this might imply that route evaluation should finally be done both > (and separately) in the server and the client. IMO the server should be > able to do a full validation of everything it gets from the clients (even > if we only partially implement such validation). But I'm not sure how you > think about that.... > > Erik. ---------------------------------------------------------------------------- -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Stefan F. (web.de) <ste...@we...> - 2010-06-26 21:32:33
|
Erik: only a few short replies. I think the choice is up to the one implementing it. My preference is B > A >>> C Option C) is in my opinion the worst. Forwarding the network information to the client only requires the network graph object. But this object has references to all vertices and edges (with further references). One would have to recode the whole network graph (which would still be larger than the list of all possible tile lays) and then define new methods working on that. The encoding of A could also be two of identifiers (hexes and tiles) and a bitset (orientation). My current approach in the map correction does not fully delegate everything to the backend, it is more a hybrid type. It only delegates the validity checks and provision of the available options to the server. The update of the UI is still done by the client controller itself and not via state changes/model updates in the server. The model state only changes after the action is fully defined/executed. (This also implies that the undo affects the full action and does not undwind partial steps). From my point of view this still allows clearer separation of responsibilities without creating additional states. Stefan On Saturday 26 June 2010 13:55:32 Erik Vos wrote: > Stefan, > > A third option could be: > > C) In addition to the "simple" LayTile of my proposal (only listing > reachable hexes), send the current routes in some form or shape from server > to client, and let the UI use these routes to sort out all laying > restrictions. I don't know if sending route information is practical, > though. > > About your options: > > A) In practice, I suppose it would be a (uuencoded serialized) List of > Lists of something. Not sure what space that would take. > Basically you're right that size would't be excessive. Just two additional > remarks: > - in my experience, it always pays off to keep traffic small, > - don't forget that there will be a lot more stuff to transport from server > to client. To name the probably biggest thing: all Observer updates. > > B) Partial actions I have been weeding out consistently since the early > days, but I understand we now have them back already... > (Yes, I remember we have had some discussions about that in the past). > One drawback would be that more state needs be maintained (I suppose that's > what you refer to as complexity). > Another reason I'm somewhat concerned about this approach is that it might > pose restrictions on further developments. > One use case I have in mind is a future PBEM version. Will the users have > stand-alone clients, exchanging messages over a slow channel, or will they > all have full-blown Rails versions, sending mails to each other and/or to > some central moderator? Most likely it'll be the latter, and then my > concern is moot, but I'm not sure. Perhaps is just a matter of intuition. > > Facing a choice, my current order of preference would be A, C, B. > > Erik. > > > -----Original Message----- > From: Stefan Frey (web.de) [mailto:ste...@we...] > Sent: Friday 25 June 2010 23:05 > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3 > > Erik: > I have some doubts that splitting the support of the tile lay between the > UI > > and the server is optimal. Especially if both have to do route > calculations. > > To allow lightweight clients in the long run (think a browser), that part > should be server only. > > I think there are two alternative options to consider: > > A) Are you really convinced that the message size for a complete list of > possible tile lays and orientations is excessive? Assume that you have 20 > hexes with 6 tiles each to replace. That is 120 combinations and each hex > and > tile can be identified by 2 bytes. A bitset for the 6 orientations would be > another 1 byte. Thus overall a 600 bytes message. Even ten times larger > should work. > > B) The client could ask the sequentially about the available options: First > the server supplies a list of hexes, the UI selects the hex, the server > response with available tiles, after tile selection, possible orientations > are transmitted. > I used this approach of partially completed actions for the map correction > action, however for a different reason. > > Between the two approaches I am personally indifferent, B) is somehow more > complex to implement, but has the advantage that all logic stays in the > backend. > > >From a network point of view solution A) is preferred, if the restricting > > factor is latency, B) to solve bandwidth issues. > > Stefan > > On Friday 25 June 2010 15:16:25 Erik Vos wrote: > > [EV] Yes, in principle you are right on the client/server task division. > > But in this case, it would mean that the server would need to send to the > > client a full list of all tiles in all valid orientation that can be laid > > in any layable hex. Although that would be the right thing to do in > > theory, > > > it would overload the client/server communication a bit, to my taste. > > > > LayTile is already prepared to carry a list of layable hexes. My > > preference > > > would be to use only such a list, and leave sorting out the valid tiles > > and > > > orientations to the UI. Most of that is based on the current map and the > > static tile upgrade specifications (any static info is always available > > to the UI). Then the only missing info in the client is about any allowed > > lays > > > in unreachable hexes (already passed in special LayTile actions) and any > > reachable but disallowed hexes (partly covered in special code, partly > > yet uncovered, I think). Starting to use that list of layable hexes might > > fix the latter hole. > > > > However, this might imply that route evaluation should finally be done > > both > > > (and separately) in the server and the client. IMO the server should be > > able to do a full validation of everything it gets from the clients (even > > if we only partially implement such validation). But I'm not sure how you > > think about that.... > > > > Erik. > > --------------------------------------------------------------------------- >- -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > --------------------------------------------------------------------------- >--- This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |