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: John A. T. <ja...@ja...> - 2011-03-13 18:58:12
|
On Sun, Mar 13, 2011 at 4:17 AM, Scott Petersen <sc...@re...>wrote: > Is there a way to implement these fairly common rules that about how to > modify share price after sales? > > 1. Current Market Value falls one space per "block" of shares sold. > 2. Current Market Value falls only when the President sells shares (no > effect if other shareholders sell). > While considering this, consider other related issues: - whether you can sell in the first SR - may sell companies that haven't operated, as normal (1830) - may sell companies that haven't operated, but receive the destination share price rather than the starting one (as in 1844) - may not sell companies that haven't operated (most DH games) -- John A. Tamplin |
From: Erik V. <eri...@xs...> - 2011-03-13 18:12:11
|
> Van: Rick Westerman [mailto:wes...@pu...] Ideally a turn > would look like: > > 1) Rails notifies you that it is your turn; e.g. through a > flashing icon on the rails window, via a taskbar flashing, audio, etc. > 5) You start off with current data (i.e., Rails has automatically > loaded in the game file) in front of you; do buy/sells as desired. > 6) You click the 'done/save' button This should not be too difficult to do. The trigger would not be any button, but just a change of who has the turn. Every, say, 30 seconds Rails could check for new files, load these, and display the results. A popup would signal your next turn. I'll try to write down a more detailed specification shortly. > Van: John A. Tamplin [mailto:ja...@ja...] I am just saying storing > files on a server and picking them up, loading and processing the file, saving > the file, etc is highly inefficient for running a distributed game, compared to > all clients seeing all the actions from the server as they happen and getting > notification directly that it is your turn rather than waiting for dropbox to > replicate the save file, Rails noticing the file is updated (which is also > problematic to notice when replication is complete to avoid reading a partially > replicated file), and replaying all the actions in the game to get to the state > for the next turn, etc. It isn't that bad: the game isn't replayed. All Reload does is checking if the saved actions are identical to those in the local processed-actions stack. Only new actions are processed. Of course I agree that true client/server would be a lot more efficient. But if I were you, I wouldn't hold my breath waiting to see that completed. If fairly simple features like Reload and Autosave/load (my proposed name of the new feature) enable Rails users to achieve near-real time play, I'm all for it to implement these first. Erik. |
From: John A. T. <ja...@ja...> - 2011-03-13 13:20:22
|
On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...>wrote: > Any ideas on how to implement the "foreigners buy a train at the end of the > set of ORs" rules that some Double-O games use (at least 1824/1844)? I am > doing a workaround for my prototype by putting a well-funded company that > starts in the bottom left space of the stock market. That way it always > runs last and is in the yellow zone so it doesn't count as a certificate for > the President. Luckily, it is an infinite bank, so no issue with cash > movements. It seems to work in the meantime until I finalize the design, > but does anyone have a more elegant way of doing this? It would be worth > implementing this mechanism at some point. I will probably work on 1824 as > my next Rails project. > > For those that are not familiar, the "foreigners buy" rule is that at the > end of a set of ORs, the top train on the stack is discarded from the game. > This could trigger the start of a new phase. 18FR-RCE does something > similar, but allows the foreigners to discard two trains if they are of > different rank. Another variant on this is to have the foreigners buy a > train after every OR rather than set--I'm still experimenting with that. > I think it is going to require Java code to implement. When implementing, consider variations, such as 1861 where the Russian state railroad buys trains as it has cash available. -- John A. Tamplin |
From: Scott P. <sc...@re...> - 2011-03-13 08:28:38
|
Any ideas on how to implement the "foreigners buy a train at the end of the set of ORs" rules that some Double-O games use (at least 1824/1844)? I am doing a workaround for my prototype by putting a well-funded company that starts in the bottom left space of the stock market. That way it always runs last and is in the yellow zone so it doesn't count as a certificate for the President. Luckily, it is an infinite bank, so no issue with cash movements. It seems to work in the meantime until I finalize the design, but does anyone have a more elegant way of doing this? It would be worth implementing this mechanism at some point. I will probably work on 1824 as my next Rails project. For those that are not familiar, the "foreigners buy" rule is that at the end of a set of ORs, the top train on the stack is discarded from the game. This could trigger the start of a new phase. 18FR-RCE does something similar, but allows the foreigners to discard two trains if they are of different rank. Another variant on this is to have the foreigners buy a train after every OR rather than set--I'm still experimenting with that. |
From: Scott P. <sc...@re...> - 2011-03-13 08:18:17
|
Is there a way to implement these fairly common rules that about how to modify share price after sales? 1. Current Market Value falls one space per "block" of shares sold. 2. Current Market Value falls only when the President sells shares (no effect if other shareholders sell). |
From: Aliza P. <ali...@gm...> - 2011-03-12 21:02:12
|
(Note: my example is a what-if run-forward of a current PbeM game. James, Jevon, Jerry, Breno, Scott, please go away.) . . Rails 1.4.1, 1856, CGR running 3 Diesels. (This is not completely absurd -- my plausible choices for the CGR in this game are 5,6; D,5; and D,D,D. The money doesn't work out right for D,D. This is a very odd game where the CGR formed with 4,5,6, and ten excellent tokens) At first, run calculations were taking 15-20 minutes on a T60 laptop running Windows XP. Now, though, I've got a calculation that's been running for well over an hour, taking 45-55% of my CPU the whole time. The map isn't that much more developed! [added - it finally completed. $1440 per 10% share.] Earlier, I was all ready to file a Rails bug because I could clearly see a better route than what was displayed, but I stepped away from my computer and when I came back, a better run was shown instead. So, one simple request: when Rails is still calculating a run, there should be a note on the screen saying something like "route calculation in progress." (Screen shot attached. Even I can quickly see that the light blue train should run towards the WGB tokens for an extra $60 on the run, and in fact Rails eventually did $10 or $20 better than that.) The next thing is that I'd like to know what was autocalculated versus hand-entered. A note in the logfile saying what the calculated run was would be very useful. (Yes, I could go back in the history and look for myself, but that's not always feasible.) Finally, any interrupt between calculating a run and entering it restarts the calculation -- even things like saving the file or entering the destination of another company. Highly annoying, though not quite a bug. |
From: Aliza P. <ali...@gm...> - 2011-03-12 16:41:22
|
I've just run into the same problem in Rails 1.4.1and filed bug 3207870 On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote: > Never mind, I could reproduce the problem as described below, and have fixed > it. > Can’t upload it now (SVN seems down) so that will be done tomorrow. > > Erik. > > -----Original Message----- > From: Erik Vos [mailto:eri...@xs...] > Sent: Friday 26 March 2010 00:00 > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz' > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price > > Ah, you mean that sales of 15% and 5% have added up? > If that is what has happened, I think I know what has caused this. > A saved file would of course help a lot... > > Erik. > > > > -----Original Message----- > From: Joshua Gottesman [mailto:jos...@gm...] > Sent: Thursday 25 March 2010 22:56 > To: Aliza Panitz > Cc: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price > > Yeah, I didn't even notice that. I just expected it to keep the price > the same. I suspect what happened is it counted your 15% and held the > 1/2 share and then combined that with my 1/2 share for another price > drop. Which is incorrect. > > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...> > wrote: >> Rails 1.2.2 bug: >> >> Selling a single 5% share of the CGR to the pool should not have >> changed the stock >> price. >> >> To quote the rules: >> >> ============== >> The share value tokens move: >> >> Down one row for each full 10% share sold either during a stock round >> or during a forced sale by a company president. The sale of a single >> 5% share does not affect the share value token. Sales of multiple 5% >> shares move the share value token >> ============== >> >> To quote the game report: >> ] Joshua sells a 5% share of CGR to Pool for $90. >> ] CGR price goes from $90(E2) to $80(E3). >> >> >> I'll file an official bug later if nobody else gets to it first. >> >> - Aliza >> >> 2010/3/25 Joshua Gottesman <jos...@gm...>: >> - Hide quoted text - >>> ================== >>> Start of Stock Round 6 >>> ================== >>> Aliza has the Priority Deal >>> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300. >>> CGR price goes from $100(E1) to $90(E2). >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank >>> Joshua sells a 5% share of CGR to Pool for $90. >>> CGR price goes from $90(E2) to $80(E3). >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank >>> >> |
From: brett l. <bre...@gm...> - 2011-03-11 16:05:07
|
On Fri, Mar 11, 2011 at 6:46 AM, John A. Tamplin <ja...@ja...> wrote: > On Fri, Mar 11, 2011 at 8:42 AM, Rick Westerman <wes...@pu...> > wrote: >> >> I also do not wish to disparage John Tamplin's (and others) ideas about >> using Google Apps or similar in order to provide for a more intelligent >> client/server, cloud, HTML5 way of approaching the usability issues. The >> above are more my thoughts on 'can we make Rails more usable with some >> tweaks' rather than a way of saying "this is the best way to do things." > > I am just saying storing files on a server and picking them up, loading and > processing the file, saving the file, etc is highly inefficient for running > a distributed game, compared to all clients seeing all the actions from the > server as they happen and getting notification directly that it is your turn > rather than waiting for dropbox to replicate the save file, Rails noticing > the file is updated (which is also problematic to notice when replication is > complete to avoid reading a partially replicated file), and replaying all > the actions in the game to get to the state for the next turn, etc. > Note that I am not saying that HTML5 is needed, just suggesting that was a > way to get a client to run across platforms including iPhone/iPad/Pre, which > otherwise would be hard to target with a Java codebase. > -- > John A. Tamplin > Moving to a client/server model also solves many of these same problems. If we can have a server process running somewhere that people can connect to, play their turn, and optionally disconnect, that solves much of the same file shuffling problems. The server could be set up with a REST or XMLRPC interface, or something similar that allows the creation of a web-based front end while still allowing more full-featured clients to work as well. I think I may have some time in the near future to work on getting the code in better shape to support something like this. ---Brett. |
From: John A. T. <ja...@ja...> - 2011-03-11 15:24:25
|
On Fri, Mar 11, 2011 at 8:42 AM, Rick Westerman <wes...@pu...>wrote: > I also do not wish to disparage John Tamplin's (and others) ideas about > using Google Apps or similar in order to provide for a more intelligent > client/server, cloud, HTML5 way of approaching the usability issues. The > above are more my thoughts on 'can we make Rails more usable with some > tweaks' rather than a way of saying "this is the best way to do things." > I am just saying storing files on a server and picking them up, loading and processing the file, saving the file, etc is highly inefficient for running a distributed game, compared to all clients seeing all the actions from the server as they happen and getting notification directly that it is your turn rather than waiting for dropbox to replicate the save file, Rails noticing the file is updated (which is also problematic to notice when replication is complete to avoid reading a partially replicated file), and replaying all the actions in the game to get to the state for the next turn, etc. Note that I am not saying that HTML5 is needed, just suggesting that was a way to get a client to run across platforms including iPhone/iPad/Pre, which otherwise would be hard to target with a Java codebase. -- John A. Tamplin |
From: Rick W. <wes...@pu...> - 2011-03-11 13:42:26
|
There was a lively discussion on the 18xx list as to how to make Rails a faster game for electronic interactive play. Certainly the recent addition of 'reload' helps a lot. Thanks! However in the 18xx list John Tamplin was saying that Rails is simply too clunky for good interactive play. Other people were saying, bah, Rails works fine with Dropbox or similar services. Some of the conversation is quoted below in case you wish to review it. I am going to take the middle road and say that Rails is clunky but with a few improvements it could be much better. In considering how people play, I suspect that all of us can agree that a player turn should consist of action(s) followed by a confirmation that the player turn is complete. In other words people should have the ability to consider the ramifications of their turn before committing to it. A possible exception are phases such as the initial round where the action is a simple single option (e.g., bid, buy or pass). At least that is the way I play in real life. In other words when a person is running a company the official order of play is often tile, token, calculate run, payment, train purchase. If a person does a tile, etc. up to the point of purchasing a train and then decides that a different tile and withholding would allow him to purchase a train we allow him to rollback his turn. We might groan but until he says "I'm done" then he has flexibility. With that in mind let us look at a typical player SR turn in Rails using Dropbox and see where the clunky parts are: 1) Somehow detect that it is your turn (e.g., Dropbox pops up a notice of a new file or you notice a new file in the directory or your friends send you reminder email/phone calls/text messages) 2) Select the 'reload' option (file location automatically generated; e.g., the Dropbox folder) 3) Scroll down through a perhaps long list of previously saved turns and select a file. 4) Click the 'open' button. 5) Do buy/sells as desired, clicking those buttons. 6) Click the 'done' button. 7) Select the 'save' option. 8) Click the 'save' button (file name and location automatically generated) While the above is fairly fast, and with the 'reload' option much faster than before when there was also the required steps of (9) close the program and (0) open the program, there are still a number of steps that could be eliminated. Ideally a turn would look like: 1) Rails notifies you that it is your turn; e.g. through a flashing icon on the rails window, via a taskbar flashing, audio, etc. 5) You start off with current data (i.e., Rails has automatically loaded in the game file) in front of you; do buy/sells as desired. 6) You click the 'done/save' button An elimination of many steps -- and perhaps more important the elimination of the repetitive boring steps. A similar argument could be made for ORs and initial rounds. Now I am not offering to do the coding -- once again my unfamiliarity with Java and a lack of time to learn it are interfering -- however speaking as a non-Java programmer I can see that it should be straightforward to have (1) a combination 'done' and 'save' button plus (2) a background job inside Rails that would look for the proper incoming file in order to do 'reload', 'select', 'open', 'notify' actions. Perhaps not easy to program but at least logical enough to program. Of course we would still want a way to run Rails without doing all of the automatic saving. One strength of Rails is the ability to do 'what if' scenarios. I also do not wish to disparage John Tamplin's (and others) ideas about using Google Apps or similar in order to provide for a more intelligent client/server, cloud, HTML5 way of approaching the usability issues. The above are more my thoughts on 'can we make Rails more usable with some tweaks' rather than a way of saying "this is the best way to do things." -- Rick ----- Original Message ----- > Why do you have to upload it? If you load the file from Dropbox, it > will by > default save it in the same Dropbox folder. > > Thus, it's simply: > > load a game save file, click pass, save the game > > Not going to get much easier than that without *significant* changes > to > Rails. > > On a related note, the next version of Vassal will include a math > engine. At > that time, I hope to edit my Vassal mod to include the kind of > automatic > math functionality (minus route calculation) that is currently found > in > Rails. > > Vassal supports live play as well as PBEM. > > -Tim > > > On Thu, Mar 10, 2011 at 4:50 PM, John A. Tamplin <ja...@ja...> wrote: > > > > > > > On Thu, Mar 10, 2011 at 4:46 PM, Stefan Filonardi <jk...@gm...> > > wrote: > > > > > Too slow? > > > > > > Rails with reload function + dropbox is almost faster than I can > > > handle. > > > > > > > So, have you ever played an on-line game? Think about during the > > private > > auction, I should just be able to click on pass and be done with it. > > Having > > to load a game save file, click pass, save the game, upload the file > > just > > seems primitive for an interactive game. I'm not saying you can't do > > it, > > but it is ridiculously slow and cumbersome compared to just playing > > an > > online game. > > > > -- > > John A. Tamplin > > > > [Non-text portions of this message have been removed] > > > > > > > |
From: brett l. <bre...@gm...> - 2011-03-11 06:15:26
|
There's only minimal tile laying enforcement. IIRC, the only thing that's enforced is when a tile is positioned next to another tile, we calculate that the track must align with the already placed tile's track. Beyond that, the app will let you do just about anything. ---Brett. On Thu, Mar 10, 2011 at 9:31 PM, Stefan Filonardi <jk...@gm...> wrote: > Hello, > > what kind of rules are enforced in Rails about tile placement? > > Is it a bug or an actual limitation of Rails that the UR can lay a tile on > Takamatsu in the attached file? > > ciao stefan > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Stefan F. <jk...@gm...> - 2011-03-11 05:31:33
|
Hello, what kind of rules are enforced in Rails about tile placement? Is it a bug or an actual limitation of Rails that the UR can lay a tile on Takamatsu in the attached file? ciao stefan |
From: Gmail <de...@gm...> - 2011-03-11 00:30:14
|
Hey Justin, There is some '25 specific code already committed but it's pretty light. I've played a playtest game through already and it played up to the point where someone wants to sell into receivership where we stalled. I've worked on the receivership code on and off (I'm learning too) and it's certainly not yet working. I think if this bit was operational you would mostly be able to play U1 or 2 to completion (no support for the funky trains in U3 or the minors yet). Phil On 10 Mar 2011, at 19:14, Justin Rebelo <jus...@gm...> wrote: > Okay, thanks Erik. > > I don't personally have the mettle to play solo play tests (too > boring), so I'm going to look for a player or two to do some testing > of Unit 1 at least and see how completely playable that is. I'll touch > base with Phil offline, he and I already do some live games together. > > If anyone wants to do a simple (Unit 1, no regions) play test with me > over email, ping me offlist. I'll play 2 or 3P game. Let's just play > fast and loose. I don't care about winning, I just want to test out > the start to finish process to see what's needed still. > > Justin > > On Thu, Mar 10, 2011 at 4:09 PM, Erik Vos <eri...@xs...> wrote: >> IIRC, it's Phil Davies who started work on 1825. So far, no special code >> has been written for it, except perhaps for route/revenue calculation (by >> Stefan Frey, but I'm not sure in what state that is). I haven't checked >> which rules cannot yet be implemented in XML and must be specially coded. >> >> However, the first step in implementing a new game always is creating the >> XML configuration files. >> The map has been done for all units and kits, and all special tiles exist, >> but companies, tile quantities, money etc. has only been defined for Unit 1 >> so far. >> So even without programming there's still a lot to do with the XML files. >> >> A test run would certainly be helpful. >> >> Erik. >> >>> -----Oorspronkelijk bericht----- >>> Van: Justin Rebelo [mailto:jus...@gm...] >>> Verzonden: donderdag 10 maart 2011 23:30 >>> Aan: Development list for Rails: an 18xx game >>> Onderwerp: [Rails-devel] 1825 Status >>> >>> Now that I've got eclipse with rails SVN running, I loaded up a quick test >> of >>> 1825 during my break at work with 2 phony players and stepped through a >>> few operating rounds. I haven't tested to see that all rules are being >> adhered >>> to (I did note that it allows a company to place two adjacent yellow >> tiles), but >>> I think rules enforcement is a nice-to-have thing after the game is >> otherwise >>> playable. >>> >>> Can someone who has been working on the 1825 development sound in on >>> what the current expected state of the game is in SVN? >>> >>> If there's no known serious blocker stopping a game from being played >>> properly, then I'd be interested in helping with 1825 implementation by >>> doing a pbem play test of the game and noting all of the outstanding >> issues >>> which I can then compile into a list to be reviewed. I'll check wherever >> the >>> system will let me break a rule and make notes of that, also checking all >> of >>> the route calculations to see if it's miscalculating or not finding >> optimal runs. >>> >>> I hope that at some point I'll be able to contribute something in terms of >>> development, but I'm a self-taught (and by experience) programmer and my >>> languages I've always worked with are interpreted (php/perl/ruby), so Java >> is >>> a pretty big shift for me. Looking through the code, I can follow >> generally >>> where things are happening, but it will be some time before I think I can >>> contribute anything meaningful in that regard. As such, I was hoping that >> I >>> could help by contributing testing time and reporting issues in the form >> of >>> bug or enhancement requests to get a scope of what's remaining to >>> implement for 1825 support and then hopefully we can move towards >>> implementing each unit and regional kit. >>> >>> I think 1825 is a pretty good title to be working towards, since its rules >> are a >>> basis for some other good games like 1853 or 1860 and its modular system >>> give it a lot of interesting replayability options. >>> >>> Justin >>> >>> >> ---------------------------------------------------------------------------- >> -- >>> Colocation vs. Managed Hosting >>> A question and answer guide to determining the best fit for your >>> organization - today and in the future. >>> http://p.sf.net/sfu/internap-sfd2d >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Justin R. <jus...@gm...> - 2011-03-11 00:14:11
|
Okay, thanks Erik. I don't personally have the mettle to play solo play tests (too boring), so I'm going to look for a player or two to do some testing of Unit 1 at least and see how completely playable that is. I'll touch base with Phil offline, he and I already do some live games together. If anyone wants to do a simple (Unit 1, no regions) play test with me over email, ping me offlist. I'll play 2 or 3P game. Let's just play fast and loose. I don't care about winning, I just want to test out the start to finish process to see what's needed still. Justin On Thu, Mar 10, 2011 at 4:09 PM, Erik Vos <eri...@xs...> wrote: > IIRC, it's Phil Davies who started work on 1825. So far, no special code > has been written for it, except perhaps for route/revenue calculation (by > Stefan Frey, but I'm not sure in what state that is). I haven't checked > which rules cannot yet be implemented in XML and must be specially coded. > > However, the first step in implementing a new game always is creating the > XML configuration files. > The map has been done for all units and kits, and all special tiles exist, > but companies, tile quantities, money etc. has only been defined for Unit 1 > so far. > So even without programming there's still a lot to do with the XML files. > > A test run would certainly be helpful. > > Erik. > >> -----Oorspronkelijk bericht----- >> Van: Justin Rebelo [mailto:jus...@gm...] >> Verzonden: donderdag 10 maart 2011 23:30 >> Aan: Development list for Rails: an 18xx game >> Onderwerp: [Rails-devel] 1825 Status >> >> Now that I've got eclipse with rails SVN running, I loaded up a quick test > of >> 1825 during my break at work with 2 phony players and stepped through a >> few operating rounds. I haven't tested to see that all rules are being > adhered >> to (I did note that it allows a company to place two adjacent yellow > tiles), but >> I think rules enforcement is a nice-to-have thing after the game is > otherwise >> playable. >> >> Can someone who has been working on the 1825 development sound in on >> what the current expected state of the game is in SVN? >> >> If there's no known serious blocker stopping a game from being played >> properly, then I'd be interested in helping with 1825 implementation by >> doing a pbem play test of the game and noting all of the outstanding > issues >> which I can then compile into a list to be reviewed. I'll check wherever > the >> system will let me break a rule and make notes of that, also checking all > of >> the route calculations to see if it's miscalculating or not finding > optimal runs. >> >> I hope that at some point I'll be able to contribute something in terms of >> development, but I'm a self-taught (and by experience) programmer and my >> languages I've always worked with are interpreted (php/perl/ruby), so Java > is >> a pretty big shift for me. Looking through the code, I can follow > generally >> where things are happening, but it will be some time before I think I can >> contribute anything meaningful in that regard. As such, I was hoping that > I >> could help by contributing testing time and reporting issues in the form > of >> bug or enhancement requests to get a scope of what's remaining to >> implement for 1825 support and then hopefully we can move towards >> implementing each unit and regional kit. >> >> I think 1825 is a pretty good title to be working towards, since its rules > are a >> basis for some other good games like 1853 or 1860 and its modular system >> give it a lot of interesting replayability options. >> >> Justin >> >> > ---------------------------------------------------------------------------- > -- >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit for your >> organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Erik V. <eri...@xs...> - 2011-03-11 00:09:14
|
IIRC, it's Phil Davies who started work on 1825. So far, no special code has been written for it, except perhaps for route/revenue calculation (by Stefan Frey, but I'm not sure in what state that is). I haven't checked which rules cannot yet be implemented in XML and must be specially coded. However, the first step in implementing a new game always is creating the XML configuration files. The map has been done for all units and kits, and all special tiles exist, but companies, tile quantities, money etc. has only been defined for Unit 1 so far. So even without programming there's still a lot to do with the XML files. A test run would certainly be helpful. Erik. > -----Oorspronkelijk bericht----- > Van: Justin Rebelo [mailto:jus...@gm...] > Verzonden: donderdag 10 maart 2011 23:30 > Aan: Development list for Rails: an 18xx game > Onderwerp: [Rails-devel] 1825 Status > > Now that I've got eclipse with rails SVN running, I loaded up a quick test of > 1825 during my break at work with 2 phony players and stepped through a > few operating rounds. I haven't tested to see that all rules are being adhered > to (I did note that it allows a company to place two adjacent yellow tiles), but > I think rules enforcement is a nice-to-have thing after the game is otherwise > playable. > > Can someone who has been working on the 1825 development sound in on > what the current expected state of the game is in SVN? > > If there's no known serious blocker stopping a game from being played > properly, then I'd be interested in helping with 1825 implementation by > doing a pbem play test of the game and noting all of the outstanding issues > which I can then compile into a list to be reviewed. I'll check wherever the > system will let me break a rule and make notes of that, also checking all of > the route calculations to see if it's miscalculating or not finding optimal runs. > > I hope that at some point I'll be able to contribute something in terms of > development, but I'm a self-taught (and by experience) programmer and my > languages I've always worked with are interpreted (php/perl/ruby), so Java is > a pretty big shift for me. Looking through the code, I can follow generally > where things are happening, but it will be some time before I think I can > contribute anything meaningful in that regard. As such, I was hoping that I > could help by contributing testing time and reporting issues in the form of > bug or enhancement requests to get a scope of what's remaining to > implement for 1825 support and then hopefully we can move towards > implementing each unit and regional kit. > > I think 1825 is a pretty good title to be working towards, since its rules are a > basis for some other good games like 1853 or 1860 and its modular system > give it a lot of interesting replayability options. > > Justin > > ---------------------------------------------------------------------------- -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit for your > organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Justin R. <jus...@gm...> - 2011-03-10 22:30:33
|
Now that I've got eclipse with rails SVN running, I loaded up a quick test of 1825 during my break at work with 2 phony players and stepped through a few operating rounds. I haven't tested to see that all rules are being adhered to (I did note that it allows a company to place two adjacent yellow tiles), but I think rules enforcement is a nice-to-have thing after the game is otherwise playable. Can someone who has been working on the 1825 development sound in on what the current expected state of the game is in SVN? If there's no known serious blocker stopping a game from being played properly, then I'd be interested in helping with 1825 implementation by doing a pbem play test of the game and noting all of the outstanding issues which I can then compile into a list to be reviewed. I'll check wherever the system will let me break a rule and make notes of that, also checking all of the route calculations to see if it's miscalculating or not finding optimal runs. I hope that at some point I'll be able to contribute something in terms of development, but I'm a self-taught (and by experience) programmer and my languages I've always worked with are interpreted (php/perl/ruby), so Java is a pretty big shift for me. Looking through the code, I can follow generally where things are happening, but it will be some time before I think I can contribute anything meaningful in that regard. As such, I was hoping that I could help by contributing testing time and reporting issues in the form of bug or enhancement requests to get a scope of what's remaining to implement for 1825 support and then hopefully we can move towards implementing each unit and regional kit. I think 1825 is a pretty good title to be working towards, since its rules are a basis for some other good games like 1853 or 1860 and its modular system give it a lot of interesting replayability options. Justin |
From: brett l. <bre...@gm...> - 2011-03-10 21:13:18
|
On Thu, Mar 10, 2011 at 12:53 PM, Justin Rebelo <jus...@gm...> wrote: > Brett, > > That's an interesting thought (probably more suited for the rails mail > list), but do you think that android devices are up to the task? I > have an android 2.1 smartphone and while I quite like it, the > processing power on-board doesn't seem to me like it would be up to > snuff for running something as substantial as rails, even as a > stripped down moderator interface. > Right now, the biggest CPU consumer is the route calculation code. A stripped down moderator interface likely wouldn't have a map mode at all, which would eliminate the need for route calculation. So, yes, I think a smartphone is a viable platform. > Something that I think COULD work very well on an android device would > be if you could create a web front-end to rails to serve as a > moderator so that it has some forms and a dashboard display of some > sort with game state and then use the rails code to drive the server > that presents this front-end UI. This would make it essentially > compatible with any device that can open a browser and make HTTP > requests (i.e. HTPC appliances, iPads, etc). > > I don't know much about java, but I seem to think something like this > could be in the realm of possibility? Even if there was just an API to > communicate with a rails server, then anyone could code any type of > front-end they wish using the API calls to send and receive data > to/from the server. > We've tried to maintain a certain amount of model-view separation for exactly this reason. The Swing-based front-end is only the default. Early on in our development, Erik had an HTML-based front-end. It hasn't seen development in a very long time, but if there's interest, someone could certainly rekindle that effort. ---Brett. > > On Thu, Mar 10, 2011 at 12:46 PM, brett lentz <wak...@gm...> wrote: >> Being that Android apps are effectively Java apps, a couple of months >> ago I had the thought of investigating the amount of effort it would >> take to make Rails suitable for Android. It would be cool to support >> a mobile version that is more focused on use as a moderator. >> >> >> ---Brett. >> >> >> >> On Thu, Mar 10, 2011 at 11:33 AM, Steve Undy <st...@ro...> wrote: >>> My first suggestion is to make it as cross-platform as possible. There are >>> a lot of Mac and Linux users out there. Running on iOS and Android would be >>> fantastic, too. >>> >>> Steve Undy >>> st...@ro... >>> >>> >>> On Thu, Mar 10, 2011 at 10:43 AM, edpovi <ed...@ya...> wrote: >>> >>>> >>>> >>>> >>>> I have been working in my free time two write a Windows program that >>>> run/moderates an 18XX game. While I'm doing this as a personal hobby >>>> project, I have though that there may be some others that would also >>>> make use of a Windows App. I thought it would be good to ask here what >>>> features would be desired for such an application? >>>> >>>> I started this due to some difficulty using the "Lemmi" >>>> moderator, partly because it's in German and partly because of my >>>> preference of the visual appearance of Windows app over that of a DOS >>>> app. I'm also using this project to "exercise" my >>>> programming skills that I haven't used in some years using Visual >>>> Studio 2010. >>>> >>>> I'm working with games I actually own for now and started with the >>>> relatively simple Railroad Barons. With that game mostly completed, >>>> I'm now moving on to Poseidon, and eventually to 1856, 1870, 1860, >>>> and 1853. I also plan to incorporate the new 1830 once that is >>>> available, and have a copy in my hands. >>>> >>>> I plan to design a utility that will be used to generate game >>>> configuration files that, in principle, will allow other 18XX games to >>>> be moderated. But, I would need to know which other sets of rules I >>>> should know to enable this flexibility. Which sets you you suggest? >>>> >>>> Thanks, >>>> >>>> Ed >>>> >>>> [Non-text portions of this message have been removed] >>>> >>>> >>>> >>> >>> >>> [Non-text portions of this message have been removed] >>> >>> >>> >>> ------------------------------------ >>> >>> This is a message from the 18xx mailing list.Yahoo! Groups Links >>> >>> >>> >>> >> >> >> ------------------------------------ >> >> This is a message from the 18xx mailing list.Yahoo! Groups Links >> >> >> >> > > > ------------------------------------ > > This is a message from the 18xx mailing list.Yahoo! Groups Links > > <*> To visit your group on the web, go to: > http://groups.yahoo.com/group/18xx/ > > <*> Your email settings: > Individual Email | Traditional > > <*> To change settings online go to: > http://groups.yahoo.com/group/18xx/join > (Yahoo! ID required) > > <*> To change settings via email: > 18x...@ya... > 18x...@ya... > > <*> To unsubscribe from this group, send an email to: > 18x...@ya... > > <*> Your use of Yahoo! Groups is subject to: > http://docs.yahoo.com/info/terms/ > > |
From: Stefan F. <jk...@gm...> - 2011-03-09 18:26:58
|
Hello, Am 17.02.2011 13:52, schrieb ab...@o2... about TileDesigner1.3.1: > Also it does not open the > TileDictionary.18t which I downloaded from that page. I think I found a solution to this: - Open the TileDictionary.18t with an editor - Replace in the second row the word Tiles with Collection - Save the file Enjoy :) ciao stefan |
From: brett l. <bre...@gm...> - 2011-03-09 15:48:59
|
On Wed, Mar 9, 2011 at 12:19 AM, Scott Petersen <sc...@re...> wrote: > Are there any games that are "off limits" for implementation in Rails due to > rightsholder issues with distributing the game? There is a long list of > games that I would like to see implemented, but don't want to work on > something that is likely to later get nixed. None that I'm aware of. I know that the game designers on the yahoo 18xx mailing list are aware of the software, but that doesn't include everyone who has ever designed an 18xx game. So far, no copyright holder has objected to the project. Just be aware that if any copyright holder requests a game's removal, we will comply with the request. The only thing that we have decided to avoid is publishing or shipping any game's rules with our software. This is done to encourage people to own copies of the games they use the software to play and to avoid duplication of copyrighted materials. Similarly, all of our software's art assets are independently created and are not reproductions of any game's artwork. So, with that said... please implement away. :-) ---Brett. |
From: Scott P. <sc...@re...> - 2011-03-09 08:19:46
|
Are there any games that are "off limits" for implementation in Rails due to rightsholder issues with distributing the game? There is a long list of games that I would like to see implemented, but don't want to work on something that is likely to later get nixed. |
From: Scott P. <sc...@re...> - 2011-03-09 08:15:32
|
On Sun, Mar 6, 2011 at 1:40 PM, Erik Vos <eri...@xs...> wrote: > Scott, > > > > The issue I found with 18JR should be fixed in the current code base in > Sourceforge (It’s a generic bug). You should just update your code from > that repository. > Yes, after doing a fresh game (not a previously saved game) it works. What a great feeling to design a map and be able to run playtests/scenarios in Rails rather than taking detailed notes. Thanks for your help. I plan to contribute significantly over the next few months. |
From: Scott P. <sc...@re...> - 2011-03-09 08:05:31
|
On Tue, Mar 8, 2011 at 9:03 PM, Rick Westerman <wes...@pu...> wrote: > I was also working on 1876-30 and 1876-35 just as test cases. If any one > want that code then let me know. Otherwise maybe I'll get excited enough to > finish those off. > Rick, go for it! At least 1876-30 should be a cinch to finish off. I'd be happy to collaborate on it as I'm learning too. If you think you won't get to it, turn it over to me to finish up. Can't wait to get a 7p PBEM game going! =p |
From: brett l. <bre...@gm...> - 2011-03-09 04:50:37
|
On Tue, Mar 8, 2011 at 8:48 PM, Stefan Filonardi <jk...@gm...> wrote: > Now I just need an old hand for a week of confinement with me so > that I can pump him for informations. ;-) We're all on this list. Ask away. ;-) > > ciao stefan > ---Brett. |
From: Stefan F. <jk...@gm...> - 2011-03-09 04:48:43
|
Hello, Am 09.03.2011 04:03, schrieb Rick Westerman: > After dusting off what work I had done over a year ago, I sent my > documents (what little there are) to Stefan. Thank you. I think that adding the wiki will have a positive effect on the project. In the future when someone has the intention to volunteer, he can shift faster from the study of the past to a more productive phase. At the same time it will relieve the old hands from explaining again and again the same basics. Now I just need an old hand for a week of confinement with me so that I can pump him for informations. ;-) ciao stefan |
From: Rick W. <wes...@pu...> - 2011-03-09 03:03:47
|
----- Original Message ----- > Hello, > > [Rails-devel] No close/load ability? > Am 01.03.2011 14:19, schrieb Rick Westerman: > > I am back looking and using Rails after a year or so hiatus. > > From struggling through the archives : Rick = documentation > or > > Ghosts haunting: > > <pre> > Re: [Rails-devel] Documentation > From: Rick Westerman <westerman@pu...> - 2010-01-20 14:08 > > Freek Dijkstra wrote: > > Out of curiosity: where can I find the documentation? I could not > > find it in the tarbal or on the website. Perhaps I overlooked it. > > I'm still working on it. A large part is understanding the program > in the first place. And, as with all of us, doing this in my spare > time. > </pre> > > Where can I find the documentation? Even smithereens could be > interesting for the wiki. > > ciao stefan > After dusting off what work I had done over a year ago, I sent my documents (what little there are) to Stefan. I was also working on 1876-30 and 1876-35 just as test cases. If any one want that code then let me know. Otherwise maybe I'll get excited enough to finish those off. On a perhaps side note, and at least an exciting note, I just finished an 18AL game with my gaming buddy. The 'reload' ability helps out a lot. When we are both on-line using Dropbox it is almost like playing in real time. Very little lag. And, in fact, with the auto-calculation of routes, we may be playing faster than face-to-face. Thanks for implementing this! -- Rick |