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 D. G. <jd...@di...> - 2008-11-04 04:42:43
|
Mark Smith wrote: > No toes were hurt by the message. I was just confirming the validity of > your statement about not trusting an actual printed copy of the game. I > have seen some site, even www.18xx.net <http://www.18xx.net> have some > errors in it (like the Tile Set for 1853). If you Look at: > > http://18xx.net/tiles/1853.htm > > And See Tile # 94 and # 95, as shown are the same tile. However, if you > look at the actual copy of the game, each of these tiles should have > only 4 track segments (2 Normal, 2 Metre) in a K formation, like Tile 96 > and 97. Thank you, I didn't notice that. I've just fixed it. |
From: Mark S. <mar...@gm...> - 2008-11-03 23:28:14
|
I can say I had noticed the Map issue with 1856 when I first found the project back more than a year ago. It has been there awhile. I did not mention it since it was listed as 'Partly Playable' and you two knew about it. But I probably should have brought it up as a bug awhile back. I will see about making some obvious process in my code integration. On Mon, Nov 3, 2008 at 11:13 AM, Erik Vos <eri...@hc...> wrote: > I have implemented the variable flotation levels of 1856 (20%-60%, > depending > on the phase). > Capitalization rules from phase 4 still to do. > > This feature is using a new property of Phase that I have added: a map with > any keyword/value pairs, in this case the floatPercentages. As usual, all > phases except the first inherit all properties of the previous one as > defaults. > > > On my PC, a strange thing is happening when the 1856 map shows up: only the > left half of it is displayed. The right half does exist, as parts of it > appear when the mouse is hovering over it, but at the next action > (repaint?) > those disappear again. > > No other game map has this problem, and I can't find anything unusual in > the > 1856 Map.xml that might explain it. > > Do others have the same problem, and perhaps a sharper eye that I have in > finding the cause? > (Perhaps we need the result of Mark's work earlier than expected...) > > Erik > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Brett L. <wak...@gm...> - 2008-11-03 22:46:53
|
On Mon, 2008-11-03 at 22:07 +0100, Erik Vos wrote: > > > Perhaps you should create a new branch in CVS for it? > > > > > > > Once it's in CVS, it can't be deleted. I don't want to check it into > > CVS only to scrap it entirely or need to completely redesign it. > > > > I'd prefer to keep our CVS tree populated with active code, rather > > than my random ideas. ;-) > > I'm not familiar with CVS branching, but I thought it would allow us to work > on different versions in parallel, of course with the ultimate goal of > merging those versions in a later stage. Never mind. > I think I understand what you're saying. CVS branches are supposed to be used for working in parallel. To be honest, CVS really sucks at merging. If you've never had to do it, you should consider yourself lucky. It can be a really painful process, especially if CVS randomly decides some of your files are too different, and it just marks the whole file as conflicting and leaves you to sort out exactly why. It sounds like you feel strongly that I should bring in my changes now rather than wait until they are further along. Is that about the size of it? > > >> So, you're welcome to check the current state of things here: > > >> http://github.com/wakko666/18xx/tree/master > > > > > > I have downloaded it and tried to run client and server, but > > > 1. The compiler reports an error in the client: > > > The method actionPerformed(ActionEvent) of type > > NetworkClientWindow must > > > override a superclass method net/sourceforge/rails/client/ui > > > NetworkClientWindow.java line 77 1225706052046 65163 > > > > Hmm... I'll have to double-check that all of my changes were merged > > with the last push. For now, removing the @override decorator should > > remove the issue. > > > > > 2. I can't find a Server main method. > > > > > > > There is no server main method. Right now, when you hit the "new game" > > button, it launches both server and client (which currently don't do > > much of anything). > > OK, it now works. > > > I haven't yet added in the interface for starting > > a standalone server. I haven't quite decided what that interface will > > look like. I'm debating either a command-line interface, or adding a > > button onto the client start-up interface. > > As I'm currently always running from Eclipse, just a main() method would do. > Outside an IDE you'll need some kind of a command-line interface anyway. > Ultimately I would package it in two separate (executable) jars. > > > >> There's some fairly major reorganization that I've done, and I've > > >> totally refactored the XML parsing. > > > > > > Can you elaborate a bit on how you see XML parsing be done your way, > > > and what the perceived benefits are? What exactly was wrong with it? > > > > > > It strikes me that the XMLParser API has the dreaded > > Document, Element and > > > NodeList > > > types that I have so carefully hidden inside Tag last year... > > > Will XMLParser replace Tag, or will the former just be used > > by the latter? > > > In any case, GameInfoParser isn't using Tag. > > > > Correct. There's nothing wrong with abstracting away the details of > > the XML DOM, per se. Tag does a fine job of that. > > > > I don't think our current method is doing anything wrong. Mainly, I > > wanted to see what it looked like to collect all of the > > configureFromXML methods into one single parser structure. > > > > The one benefit that this different method adds, is that we don't have > > to wait until we initialize a specific game object in order to parse > > the XML for that object. This provides access to that information to > > things outside of that specific game object. This will avoid similar > > issues like we had adding in variants and game options. > > The only thing is, that then in some cases the XML must be interpreted to > know which game-specific XMLParser class must parse some part of it. Right. On startup, the only XML that's read is the GamesList. Once we know which game is being started, we would then read that particular game's XML, and decide which game-specific parsers are needed. > > At this point, I would consider this experimenting with a different > > method for code organization. I'm happy to scrap it to retain the > > existing methods if it doesn't provide any real benefits, or has some > > obvious problems. > > OK. I'm not too happy with the larger number of classes we will have, but > I'll drop that comment if definite benefits show up. > > > I actually see one potential benefit, although I'm not sure if you will > judge it as that. Equally well, it might just be one of the goals you are > aiming for. > > As I think I have explained before: I want to get rid of the many static > methods in various classes that return non-static and game-dependent > information. Bank.format() is an obvious point in case. The reason is, that > when the client/server split is complete, the server should be able to > accomodate multiple simultaneous games (at least potentially). > I agree with you. Static should be used sparingly, and only when absolutely necessary. > These static methods are currently needed to give all kinds of object access > to properties of "remote" objects: objects that are not directly related to > it. Ways out of this problem include: > > 1. So far I have been moving towards making all these objects directly or > indirectly known to GameManager, and passing along the GameManager object to > all places where such access is needed. I think this is a dead end: there > are too many different objects around, and putting a GameManager reference > into all of them looks ugly to me. > Agreed. > 2. We could try to make all relevant classes a subclass of one common class > (call it GameObject extends Object), and putting the GameManager reference > into GameObject. That would fix the problem in one fell swoop, but I'm not > sure if we wouldn't run into multiple inheritance problems; this need be > checked, but I think not. > > 3. The common GameManager reference could also be put into XMLParser, and > then all objects that have an XMLParser companion would have easy access to > it. But that would leave out those objects that do not parse XML, and I > think we have some of these as well. > > Actually, option 2 looks best to me, if there are no other top classes > getting in the way. To be honest, this idea only occurred to me when > thinking about my previous post in this thread. > I'm not sure I like any of these as individual solutions. I can't quite express the problems I see with those solutions in a way that I'm happy with. I've spent the last 30 minutes trying to type it out, but none of it sounds right. In general, I'd like to improve the accessor methods so that we don't require GameManager to know or do as much. For example, in Tile there's the isLayableNow() method: public boolean isLayableNow() { return GameManager.getInstance().getCurrentPhase().isTileColourAllowed(colourName); } This method is currently used exactly once in our entire codebase. This method is used in OperatingRound. In my mind, there are two problems with this. 1. Why do we need a whole new method in Tile for information that Tile doesn't even have? 2. I think that this is information that Tile *should* have. Tile shouldn't need to call all the way up to the GameManager to figure this out. One likely answer is to change isLayableNow()'s signature to be 'isLayableNow(phaseNumber)' or something similar. That way Tile has the information it needs to be authoritative for this information, rather than relying on GameManager to know this. My view is that Tile should be constructed with enough information to know these sorts of things on its own. If it needs GameManager, it's because we aren't passing in enough information to the Tile objects at construction time. To fix our overuse of static methods, I think we need to improve the accessor methods and how we're constructing our objects. When we no longer require instances of GameManager everywhere, then we no longer require GameManager to have the static getInstance() method. I believe the same logic applies to most of the other static methods we have. I hope that makes sense. > > Well, I don't know of any specific things in the game engine that need > > reorganizing. I know that when we talked about this last, you > > mentioned that you had wanted to take a different approach on some > > things. > > I only meant, that I would have started bottom-up by gradually loosening the > ties between client and server code until we have one class where all > messages would be channeled through, and then insert the communications > channel there. Your approach is top-down. Perhaps we need both: yours for > the framework, mine for the details, but we'll see. > I agree, I think we need both approaches. For the last year or so, you've been slowly improving the existing code to better support client/server behavior. I've just started on the other end of it. ;-) I think what's important is that perhaps I'm wrong about wanting to wait to commit this. Perhaps what I've got so far *is* ready for a wider audience and really should be committed into CVS. I was beginning to second-guess myself about wanting to wait longer before I committed it to the project. So, this thread was intended to get your opinions about it. I figure, if I'm not sure I'm doing it right, I should run it by someone else. :-) > Erik. > ---Brett. May all your PUSHes be POPped. |
From: Erik V. <eri...@hc...> - 2008-11-03 21:07:26
|
> > Perhaps you should create a new branch in CVS for it? > > > > Once it's in CVS, it can't be deleted. I don't want to check it into > CVS only to scrap it entirely or need to completely redesign it. > > I'd prefer to keep our CVS tree populated with active code, rather > than my random ideas. ;-) I'm not familiar with CVS branching, but I thought it would allow us to work on different versions in parallel, of course with the ultimate goal of merging those versions in a later stage. Never mind. > >> So, you're welcome to check the current state of things here: > >> http://github.com/wakko666/18xx/tree/master > > > > I have downloaded it and tried to run client and server, but > > 1. The compiler reports an error in the client: > > The method actionPerformed(ActionEvent) of type > NetworkClientWindow must > > override a superclass method net/sourceforge/rails/client/ui > > NetworkClientWindow.java line 77 1225706052046 65163 > > Hmm... I'll have to double-check that all of my changes were merged > with the last push. For now, removing the @override decorator should > remove the issue. > > > 2. I can't find a Server main method. > > > > There is no server main method. Right now, when you hit the "new game" > button, it launches both server and client (which currently don't do > much of anything). OK, it now works. > I haven't yet added in the interface for starting > a standalone server. I haven't quite decided what that interface will > look like. I'm debating either a command-line interface, or adding a > button onto the client start-up interface. As I'm currently always running from Eclipse, just a main() method would do. Outside an IDE you'll need some kind of a command-line interface anyway. Ultimately I would package it in two separate (executable) jars. > >> There's some fairly major reorganization that I've done, and I've > >> totally refactored the XML parsing. > > > > Can you elaborate a bit on how you see XML parsing be done your way, > > and what the perceived benefits are? What exactly was wrong with it? > > > > It strikes me that the XMLParser API has the dreaded > Document, Element and > > NodeList > > types that I have so carefully hidden inside Tag last year... > > Will XMLParser replace Tag, or will the former just be used > by the latter? > > In any case, GameInfoParser isn't using Tag. > > Correct. There's nothing wrong with abstracting away the details of > the XML DOM, per se. Tag does a fine job of that. > > I don't think our current method is doing anything wrong. Mainly, I > wanted to see what it looked like to collect all of the > configureFromXML methods into one single parser structure. > > The one benefit that this different method adds, is that we don't have > to wait until we initialize a specific game object in order to parse > the XML for that object. This provides access to that information to > things outside of that specific game object. This will avoid similar > issues like we had adding in variants and game options. The only thing is, that then in some cases the XML must be interpreted to know which game-specific XMLParser class must parse some part of it. > At this point, I would consider this experimenting with a different > method for code organization. I'm happy to scrap it to retain the > existing methods if it doesn't provide any real benefits, or has some > obvious problems. OK. I'm not too happy with the larger number of classes we will have, but I'll drop that comment if definite benefits show up. I actually see one potential benefit, although I'm not sure if you will judge it as that. Equally well, it might just be one of the goals you are aiming for. As I think I have explained before: I want to get rid of the many static methods in various classes that return non-static and game-dependent information. Bank.format() is an obvious point in case. The reason is, that when the client/server split is complete, the server should be able to accomodate multiple simultaneous games (at least potentially). These static methods are currently needed to give all kinds of object access to properties of "remote" objects: objects that are not directly related to it. Ways out of this problem include: 1. So far I have been moving towards making all these objects directly or indirectly known to GameManager, and passing along the GameManager object to all places where such access is needed. I think this is a dead end: there are too many different objects around, and putting a GameManager reference into all of them looks ugly to me. 2. We could try to make all relevant classes a subclass of one common class (call it GameObject extends Object), and putting the GameManager reference into GameObject. That would fix the problem in one fell swoop, but I'm not sure if we wouldn't run into multiple inheritance problems; this need be checked, but I think not. 3. The common GameManager reference could also be put into XMLParser, and then all objects that have an XMLParser companion would have easy access to it. But that would leave out those objects that do not parse XML, and I think we have some of these as well. Actually, option 2 looks best to me, if there are no other top classes getting in the way. To be honest, this idea only occurred to me when thinking about my previous post in this thread. > Well, I don't know of any specific things in the game engine that need > reorganizing. I know that when we talked about this last, you > mentioned that you had wanted to take a different approach on some > things. I only meant, that I would have started bottom-up by gradually loosening the ties between client and server code until we have one class where all messages would be channeled through, and then insert the communications channel there. Your approach is top-down. Perhaps we need both: yours for the framework, mine for the details, but we'll see. Erik. |
From: Erik V. <eri...@hc...> - 2008-11-03 19:53:47
|
I have implemented the variable flotation levels of 1856 (20%-60%, depending on the phase). Capitalization rules from phase 4 still to do. This feature is using a new property of Phase that I have added: a map with any keyword/value pairs, in this case the floatPercentages. As usual, all phases except the first inherit all properties of the previous one as defaults. On my PC, a strange thing is happening when the 1856 map shows up: only the left half of it is displayed. The right half does exist, as parts of it appear when the mouse is hovering over it, but at the next action (repaint?) those disappear again. No other game map has this problem, and I can't find anything unusual in the 1856 Map.xml that might explain it. Do others have the same problem, and perhaps a sharper eye that I have in finding the cause? (Perhaps we need the result of Mark's work earlier than expected...) Erik |
From: brett l. <wak...@gm...> - 2008-11-03 19:27:10
|
On Mon, Nov 3, 2008 at 2:41 AM, Erik Vos <eri...@hc...> wrote: >> Just a quick update... >> >> I'm still working on getting the client/server parts working. >> >> Currently, I've gotten the startup code refactored, and am just >> starting to tie it into the network bits. Unfortunately, the fall >> tends to be a busy time for me, so I haven't had as much time work on >> this as I'd have liked. >> >> I'm not quite ready to push this back into cvs yet. I'd like to get a >> bit further into having a minimally functional client/server. Being >> that this is an open source project, perhaps I shouldn't "go dark" for >> too much longer. I've been using github.com to push my changes between >> home and work, so that I can work in both places whenever I have a >> free moment. (Note: this doesn't mean we're changing revision control >> systems. This is just my personal place to store code. When I feel >> it's ready, I'll push this code back into cvs.) > > Perhaps you should create a new branch in CVS for it? > Once it's in CVS, it can't be deleted. I don't want to check it into CVS only to scrap it entirely or need to completely redesign it. I'd prefer to keep our CVS tree populated with active code, rather than my random ideas. ;-) >> So, you're welcome to check the current state of things here: >> http://github.com/wakko666/18xx/tree/master > > I have downloaded it and tried to run client and server, but > 1. The compiler reports an error in the client: > The method actionPerformed(ActionEvent) of type NetworkClientWindow must > override a superclass method net/sourceforge/rails/client/ui > NetworkClientWindow.java line 77 1225706052046 65163 Hmm... I'll have to double-check that all of my changes were merged with the last push. For now, removing the @override decorator should remove the issue. > 2. I can't find a Server main method. > There is no server main method. Right now, when you hit the "new game" button, it launches both server and client (which currently don't do much of anything). I haven't yet added in the interface for starting a standalone server. I haven't quite decided what that interface will look like. I'm debating either a command-line interface, or adding a button onto the client start-up interface. >> There's some fairly major reorganization that I've done, and I've >> totally refactored the XML parsing. > > Can you elaborate a bit on how you see XML parsing be done your way, > and what the perceived benefits are? What exactly was wrong with it? > > It strikes me that the XMLParser API has the dreaded Document, Element and > NodeList > types that I have so carefully hidden inside Tag last year... > Will XMLParser replace Tag, or will the former just be used by the latter? > In any case, GameInfoParser isn't using Tag. Correct. There's nothing wrong with abstracting away the details of the XML DOM, per se. Tag does a fine job of that. I don't think our current method is doing anything wrong. Mainly, I wanted to see what it looked like to collect all of the configureFromXML methods into one single parser structure. The one benefit that this different method adds, is that we don't have to wait until we initialize a specific game object in order to parse the XML for that object. This provides access to that information to things outside of that specific game object. This will avoid similar issues like we had adding in variants and game options. At this point, I would consider this experimenting with a different method for code organization. I'm happy to scrap it to retain the existing methods if it doesn't provide any real benefits, or has some obvious problems. > Will your reorganisation extend to replacing/rewriting the configureFromXML > methods of so many classes? Please be careful to retain the > dynamic extensibility of the XML that we have gained by having > (possibly game-specific) classes parse their own dedicated XML. Yes, this was the key thing I wanted to try in a slightly different way. What I'm looking at is splitting the game classes into two parts: the game model class, and the xml parser class. The configureFromXML method would be refactored into its own class, so that the game model class is only concerned with manipulating existing java objects. As for extensibility, that hasn't changed. The only real difference is that all of the XML code is moved to their own classes, rather than living in the game classes. >> Both of these I'd like to see >> comments on before I push this into our code repository. Things are >> still in heavy flux, so none of this is set, and I really don't want >> to shake things up too much without make sure you guys are also happy >> with it. My hope is that some of these changes will help make >> reorganizing the game engine code a little easier. > > Before I can judge all this I would like to know what your thoughts are > on the direction in which the game engine need be "reorganized". > What are your sore points? > Of course there is much work to do in the existing code to make the > client/server > split possible at all, but so far I cannot see much of that in what you have > published, > and you seem to stir up quite a bit more than just that. > Well, I don't know of any specific things in the game engine that need reorganizing. I know that when we talked about this last, you mentioned that you had wanted to take a different approach on some things. Most of what I've currently done is just refactor the initialization code to allow it to start a client and a server. I've also streamlined initialization a bit. For example, there's no longer a games.properties file required to figure out what games are available. That information is loaded directly from the GamesList.xml. > In general it is not very clear to me what direction you are taking, > and why, on matters that are not immediately related to the client/server > split (such as XML parsing). > I suspected. When I started this, I just started working from the beginning of the app's initialization. There have been some things I wanted to try doing with the start-up code as I was making it aware of needing to start a client and server. I can see how it's unclear, as there's not much of the client and server bits to show off yet. it's still mostly the start-up code with some minor tweaks, a new parser, and a radically different package layout. My main concern is that I've spent a few weeks on it without showing it to anyone, and I don't think that's the right way to do an open source project. I really don't want to just dump a major code change into CVS without having some conversations about whether I'm doing things in a way that everyone is reasonably happy with. > Erik. > > ---Brett. |
From: Mark S. <mar...@gm...> - 2008-11-03 12:03:58
|
No toes were hurt by the message. I was just confirming the validity of your statement about not trusting an actual printed copy of the game. I have seen some site, even www.18xx.net have some errors in it (like the Tile Set for 1853). If you Look at: http://18xx.net/tiles/1853.htm And See Tile # 94 and # 95, as shown are the same tile. However, if you look at the actual copy of the game, each of these tiles should have only 4 track segments (2 Normal, 2 Metre) in a K formation, like Tile 96 and 97. And Yes, the 1853 Map you have is a bit on the "messy" side...:-) No offense. Mark |
From: Erik V. <eri...@hc...> - 2008-11-03 10:41:35
|
> Just a quick update... > > I'm still working on getting the client/server parts working. > > Currently, I've gotten the startup code refactored, and am just > starting to tie it into the network bits. Unfortunately, the fall > tends to be a busy time for me, so I haven't had as much time work on > this as I'd have liked. > > I'm not quite ready to push this back into cvs yet. I'd like to get a > bit further into having a minimally functional client/server. Being > that this is an open source project, perhaps I shouldn't "go dark" for > too much longer. I've been using github.com to push my changes between > home and work, so that I can work in both places whenever I have a > free moment. (Note: this doesn't mean we're changing revision control > systems. This is just my personal place to store code. When I feel > it's ready, I'll push this code back into cvs.) Perhaps you should create a new branch in CVS for it? > So, you're welcome to check the current state of things here: > http://github.com/wakko666/18xx/tree/master I have downloaded it and tried to run client and server, but 1. The compiler reports an error in the client: The method actionPerformed(ActionEvent) of type NetworkClientWindow must override a superclass method net/sourceforge/rails/client/ui NetworkClientWindow.java line 77 1225706052046 65163 2. I can't find a Server main method. > There's some fairly major reorganization that I've done, and I've > totally refactored the XML parsing. Can you elaborate a bit on how you see XML parsing be done your way, and what the perceived benefits are? What exactly was wrong with it? It strikes me that the XMLParser API has the dreaded Document, Element and NodeList types that I have so carefully hidden inside Tag last year... Will XMLParser replace Tag, or will the former just be used by the latter? In any case, GameInfoParser isn't using Tag. Will your reorganisation extend to replacing/rewriting the configureFromXML methods of so many classes? Please be careful to retain the dynamic extensibility of the XML that we have gained by having (possibly game-specific) classes parse their own dedicated XML. > Both of these I'd like to see > comments on before I push this into our code repository. Things are > still in heavy flux, so none of this is set, and I really don't want > to shake things up too much without make sure you guys are also happy > with it. My hope is that some of these changes will help make > reorganizing the game engine code a little easier. Before I can judge all this I would like to know what your thoughts are on the direction in which the game engine need be "reorganized". What are your sore points? Of course there is much work to do in the existing code to make the client/server split possible at all, but so far I cannot see much of that in what you have published, and you seem to stir up quite a bit more than just that. In general it is not very clear to me what direction you are taking, and why, on matters that are not immediately related to the client/server split (such as XML parsing). Erik. |
From: John D. G. <jd...@di...> - 2008-11-03 04:10:53
|
Mark Smith wrote: > With regards to 1853, yes, the Rows have upper case letters, and the > columns have lower case double letters. And I do account for that in my > code. I have double-checked against my own copy of the game. > > With regards to using "The Depot" Site as a map cell name reference, I > have not used that before. Each of the maps I have encoded are based > upon copies I actually own. Sorry, I didn't mean to step on your toes, I've just run into these conflicts in PBEM play. > Erik's comment about the "non-functional land and water hexes"... Some > games, like 1853 distinguish a difference between un-useable land > hexes... some allow a railhead to connect to it, some do not. And > regardless of that, the Water hexes are partly there to make the map > appear "nicer", by more closely mimicing the actual printed board, but > also it makes the verification of legal tile lays easier ... "You cannot > dead-end into a hex side that is all water." Besides, if it really bugs > you that much, internal Lakes (like in 1856) can be set as a Lake Type, > and be drawn with a blue color, and Ocean hexes can be set as the > default background color so they are drawn, but they won't change the > background. And the goal is to have it configurable as a default setting > (for all games), and a level for a specific game, and at a level for > the individual player prefered. It would be solely based upon how your > color scheme files would be set up. I'm not sure anyone has noticed since I haven't received any comments on it, but the "map" link from http://www.18xx.net/1853.htm now points to my own version of the map, with all eight company territories shown by cross-hatching. It's a bit messy, but it makes them more visible than other versions I've seen, and I've shown all the build costs too. |
From: brett l. <wak...@gm...> - 2008-11-02 23:12:00
|
Just a quick update... I'm still working on getting the client/server parts working. Currently, I've gotten the startup code refactored, and am just starting to tie it into the network bits. Unfortunately, the fall tends to be a busy time for me, so I haven't had as much time work on this as I'd have liked. I'm not quite ready to push this back into cvs yet. I'd like to get a bit further into having a minimally functional client/server. Being that this is an open source project, perhaps I shouldn't "go dark" for too much longer. I've been using github.com to push my changes between home and work, so that I can work in both places whenever I have a free moment. (Note: this doesn't mean we're changing revision control systems. This is just my personal place to store code. When I feel it's ready, I'll push this code back into cvs.) So, you're welcome to check the current state of things here: http://github.com/wakko666/18xx/tree/master There's some fairly major reorganization that I've done, and I've totally refactored the XML parsing. Both of these I'd like to see comments on before I push this into our code repository. Things are still in heavy flux, so none of this is set, and I really don't want to shake things up too much without make sure you guys are also happy with it. My hope is that some of these changes will help make reorganizing the game engine code a little easier. Mostly, I just wanted to update everyone that this isn't vapor, and I'm still working on it. :-) ---Brett. |
From: Mark S. <mar...@gm...> - 2008-11-02 20:55:58
|
Futz... it is my Code Checkout/Update process that is getting in the way. I got a good update and it compiles fine. Sorry. On Sun, Nov 2, 2008 at 3:44 PM, Mark Smith <mar...@gm...> wrote: > The StockRound Class now generates 19 "Cannot Find Symbol" errors. > > cert.getCertificatePrice () > comp.getParPrice () > comp.getCurrentPrice () > stockSpace = company.getCurrentPrice () > > Did you check in the latest Public Company, and PublicCertificate Clases? > > Or am I still having issues getting the latest greatest code updates? > > Mark > > > On Sun, Nov 2, 2008 at 3:06 PM, Erik Vos <eri...@hc...> wrote: > >> Feeling a bit better (and having had thinking time), I have fixed the >> remaining share price bug, >> and also reorganised the price methods as follows: >> >> - PublicCompany now has 2 new methods: getStartPrice() and >> getMarketPrice() >> which return the integer price values. >> PublicCompany internally knows whether the start price is just the market >> price or a separate par price. >> All code only needing the price value now use these methods. >> >> - The existing methods getParPrice() and getCurrentPrice() have been >> renamed >> to getStartSpace() and getCurrentSpace() because these return StockSpace >> objects. Usage of these methods is now limited to cases where these >> objects >> are really needed for their other attributes. >> For consistency I have also renamed setParPrice and setCurrentPrice to >> setParSpace and setCurrentSpace. >> >> - The redundant (and confusing) method >> PublicCertificate.getCertificatePrice() has been removed. Using this >> method >> had caused the aforementioned bug. >> >> Everything now seems to work correctly, although I haven't tested all >> games, >> so I keep fingers crossed.... >> >> Erik Vos >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > |
From: Mark S. <mar...@gm...> - 2008-11-02 20:44:30
|
The StockRound Class now generates 19 "Cannot Find Symbol" errors. cert.getCertificatePrice () comp.getParPrice () comp.getCurrentPrice () stockSpace = company.getCurrentPrice () Did you check in the latest Public Company, and PublicCertificate Clases? Or am I still having issues getting the latest greatest code updates? Mark On Sun, Nov 2, 2008 at 3:06 PM, Erik Vos <eri...@hc...> wrote: > Feeling a bit better (and having had thinking time), I have fixed the > remaining share price bug, > and also reorganised the price methods as follows: > > - PublicCompany now has 2 new methods: getStartPrice() and getMarketPrice() > which return the integer price values. > PublicCompany internally knows whether the start price is just the market > price or a separate par price. > All code only needing the price value now use these methods. > > - The existing methods getParPrice() and getCurrentPrice() have been > renamed > to getStartSpace() and getCurrentSpace() because these return StockSpace > objects. Usage of these methods is now limited to cases where these objects > are really needed for their other attributes. > For consistency I have also renamed setParPrice and setCurrentPrice to > setParSpace and setCurrentSpace. > > - The redundant (and confusing) method > PublicCertificate.getCertificatePrice() has been removed. Using this method > had caused the aforementioned bug. > > Everything now seems to work correctly, although I haven't tested all > games, > so I keep fingers crossed.... > > Erik Vos > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Erik V. <eri...@hc...> - 2008-11-02 20:07:00
|
Feeling a bit better (and having had thinking time), I have fixed the remaining share price bug, and also reorganised the price methods as follows: - PublicCompany now has 2 new methods: getStartPrice() and getMarketPrice() which return the integer price values. PublicCompany internally knows whether the start price is just the market price or a separate par price. All code only needing the price value now use these methods. - The existing methods getParPrice() and getCurrentPrice() have been renamed to getStartSpace() and getCurrentSpace() because these return StockSpace objects. Usage of these methods is now limited to cases where these objects are really needed for their other attributes. For consistency I have also renamed setParPrice and setCurrentPrice to setParSpace and setCurrentSpace. - The redundant (and confusing) method PublicCertificate.getCertificatePrice() has been removed. Using this method had caused the aforementioned bug. Everything now seems to work correctly, although I haven't tested all games, so I keep fingers crossed.... Erik Vos |
From: Chris S. <chr...@gm...> - 2008-11-02 19:52:42
|
Some games (I'm thinking of 18Scan, but I'm pretty sure there are others) define playable areas in terms of hexes, and do not have hexes in the water. If you print hexes where none exist in the published game, there might be confusion about rules references. Chris On Sun, Nov 2, 2008 at 11:28 AM, Mark Smith <mar...@gm...> wrote: > I could certainly include the hex names on the Map.xml file itself without > any real difficulty. It just seemed an extra level of complexity. I do > specify at the start of my map.xml files to specify the rowStart Value, and > the Col Start Value. It all derives from those. But if it makes you happier > to see them associated with the individual map cells, sure. And as for > identifying the exact map cells that the Privates would be affecting, yes > indeed that is a valid point. But it isn't like you can build this once and > just know it will be right. There are always adjustments. And once you get > it set correctly, you leave it alone. > > With regards to 1853, yes, the Rows have upper case letters, and the columns > have lower case double letters. And I do account for that in my code. I have > double-checked against my own copy of the game. > > With regards to using "The Depot" Site as a map cell name reference, I have > not used that before. Each of the maps I have encoded are based upon copies > I actually own. > > Erik's comment about the "non-functional land and water hexes"... Some > games, like 1853 distinguish a difference between un-useable land hexes... > some allow a railhead to connect to it, some do not. And regardless of that, > the Water hexes are partly there to make the map appear "nicer", by more > closely mimicing the actual printed board, but also it makes the > verification of legal tile lays easier ... "You cannot dead-end into a hex > side that is all water." Besides, if it really bugs you that much, internal > Lakes (like in 1856) can be set as a Lake Type, and be drawn with a blue > color, and Ocean hexes can be set as the default background color so they > are drawn, but they won't change the background. And the goal is to have it > configurable as a default setting (for all games), and a level for a > specific game, and at a level for the individual player prefered. It would > be solely based upon how your color scheme files would be set up. > > Personally I do like seeing the Ocean/Great Lake drawn as a Water Hex. > > As for finding someone down the road that will generate a "pretty > background" that matches the original board exactly, and be scaleable... > well that is not on my plate right now. > > Mark > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > -- Chris Please consider the environment before printing this e-mail. |
From: Mark S. <mar...@gm...> - 2008-11-02 19:28:15
|
I could certainly include the hex names on the Map.xml file itself without any real difficulty. It just seemed an extra level of complexity. I do specify at the start of my map.xml files to specify the rowStart Value, and the Col Start Value. It all derives from those. But if it makes you happier to see them associated with the individual map cells, sure. And as for identifying the exact map cells that the Privates would be affecting, yes indeed that is a valid point. But it isn't like you can build this once and just know it will be right. There are always adjustments. And once you get it set correctly, you leave it alone. With regards to 1853, yes, the Rows have upper case letters, and the columns have lower case double letters. And I do account for that in my code. I have double-checked against my own copy of the game. With regards to using "The Depot" Site as a map cell name reference, I have not used that before. Each of the maps I have encoded are based upon copies I actually own. Erik's comment about the "non-functional land and water hexes"... Some games, like 1853 distinguish a difference between un-useable land hexes... some allow a railhead to connect to it, some do not. And regardless of that, the Water hexes are partly there to make the map appear "nicer", by more closely mimicing the actual printed board, but also it makes the verification of legal tile lays easier ... "You cannot dead-end into a hex side that is all water." Besides, if it really bugs you that much, internal Lakes (like in 1856) can be set as a Lake Type, and be drawn with a blue color, and Ocean hexes can be set as the default background color so they are drawn, but they won't change the background. And the goal is to have it configurable as a default setting (for all games), and a level for a specific game, and at a level for the individual player prefered. It would be solely based upon how your color scheme files would be set up. Personally I do like seeing the Ocean/Great Lake drawn as a Water Hex. As for finding someone down the road that will generate a "pretty background" that matches the original board exactly, and be scaleable... well that is not on my plate right now. Mark |
From: John D. G. <jd...@di...> - 2008-11-02 19:07:21
|
Mark Smith wrote: > 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch > my current product, and then let you mouse hover over a hex, a tool tip > shows you the cell name. It is not defined in the XML files, other than > the rowStart and colStart values on the first line of the Map.xml files. > Every map cell name is deduced from that and the order the cells are > shown in the file. It may be counting down, or counting up. But it does > work on five maps I have coded up so far. Now, if some games (like 1851 > with Cincinatti) have some awkward nameing sequences that may require a > change, or at least an option to include them with the map cells > definitions. 1853 is another game with an odd naming sequence for map hexes (capital letters one way, lower case the other, uses "i" but then skips "ai"...) Note: Do not rely on .gifs from David Reed's "The Depot" as a source for map hex names in general. Many of its maps get them wrong. |
From: Erik V. <eri...@hc...> - 2008-11-02 18:52:24
|
Allow me late reaction to a subject discussed a while ago: 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch my current product, and then let you mouse hover over a hex, a tool tip shows you the cell name. It is not defined in the XML files, other than the rowStart and colStart values on the first line of the Map.xml files. Every map cell name is deduced from that and the order the cells are shown in the file. It may be counting down, or counting up. But it does work on five maps I have coded up so far. Now, if some games (like 1851 with Cincinatti) have some awkward nameing sequences that may require a change, or at least an option to include them with the map cells definitions. The point is, that hex names are used a lot in configuring games, for instance to indicate hexes where certain private special properties can be exercised. Your way, that would require to first build and display the map with all preprinted tiles before the actual hex names can be found by hovering the mouse (or by looking at the printed board, hoping that the two will match). I would still prefer to find the hex names in Map.xml. A side note is, that I don't very much like and would personally prefer to leave out those nonfunctional water and land "hexes" (which aren't). Not sure what others think about this. My hope is, that someday, someone will build real maps, that can be used as a background on top of which the real (preprinted and laid) tiles are displayed. But perhaps that hope is idle... Erik. |
From: Erik V. <eri...@hc...> - 2008-11-02 16:33:58
|
Situation: Player Mark has $56 Cash. The Par Value of the Stock is $60, but the Current Market Value is $55. The Stock Info Table shows during a Stock Round that I should be able to buy an IPO Share, based upon sufficient Cash Check. I select to purchase, and the display asks to confirm that you want to buy the Share at $55 (Current Market Value -- This is wrong because I am trying to buy from IPO at PAR Value). The followup test when attempting to complete the purchase fails and generates a complaint about insufficient funds. Right. This is another consequence of the messy situation around share prices in StockRound.setBuyableCerts(), possibly caused by my recent reorganisation of that code. I'm still planning to sort this out a.s.a.p, but I'm currently somewhat ill and so it may take a bit longer than foreseen. Erik. |
From: brett l. <wak...@gm...> - 2008-11-02 16:05:15
|
On Sun, Nov 2, 2008 at 7:02 AM, Mark Smith <mar...@gm...> wrote: > I have been thinking about how to integrate my JAVA Code Base to draw tiles, > maps and functionality into Rails. My initial thought is to do this in two > main phases: > > Phase 1 - Build Tile Tray that will draw all of the tiles in the game > > Phase 2 - Build Map Frame replacement that will draw the map and all the > tiles on top. > > I am thinking that to start I would transfer my code into a separate package > rails.ui.swing.tiles and rails.ui.swing.map. The actual source would be > added to the corresponding new directories under rail/ui/swing/ directory. > > This would allow for the current production code to remain stable, and allow > me to incorporate my JAVA Code incrementally. > > Does this sound reasonable? or would you prefer I put the code in a > different place? > > Mark > Sounds reasonable to me. ---Brett. |
From: Mark S. <mar...@gm...> - 2008-11-02 14:02:24
|
I have been thinking about how to integrate my JAVA Code Base to draw tiles, maps and functionality into Rails. My initial thought is to do this in two main phases: Phase 1 - Build Tile Tray that will draw all of the tiles in the game Phase 2 - Build Map Frame replacement that will draw the map and all the tiles on top. I am thinking that to start I would transfer my code into a separate package *rails.ui.swing.tiles* and *rails.ui.swing.map*. The actual source would be added to the corresponding new directories under rail/ui/swing/ directory. This would allow for the current production code to remain stable, and allow me to incorporate my JAVA Code incrementally. Does this sound reasonable? or would you prefer I put the code in a different place? Mark |
From: Mark S. <mar...@gm...> - 2008-11-02 00:12:36
|
OK Erik and Brett, I have found, fixed, tested, committed, and updated this Bug Report, status of 'Pending'. I figure that someone else should perform a independent test before marking the issue closed, since this is my first correction start to finish. This was missing the Upgrades for Tiles 3, 4 and 58. Mark |
From: Mark S. <mar...@gm...> - 2008-11-02 00:06:12
|
Erik, Another issue with the Stock Value. I ran across a bug that is a bit obscure, but the code does prevent an illegal action: Situation: Player Mark has $56 Cash. The Par Value of the Stock is $60, but the Current Market Value is $55. The Stock Info Table shows during a Stock Round that I should be able to buy an IPO Share, based upon sufficient Cash Check. I select to purchase, and the display asks to confirm that you want to buy the Share at $55 (Current Market Value -- This is wrong because I am trying to buy from IPO at PAR Value). The followup test when attempting to complete the purchase fails and generates a complaint about insufficient funds. This might not come up much, but the code is comparing Current Cash against Current Stock Value and not against Par Value for IPO Purchases. Mark |
From: Mark S. <mar...@gm...> - 2008-10-31 22:49:17
|
Hmmm... it must have been the Puppy... I re-checked and found I had updated the code but not rebuilt it. It does operate properly. Sorry for the mis-report. Mark On Fri, Oct 31, 2008 at 4:25 PM, Mark Smith <mar...@gm...> wrote: > I ran through a quick test on 1830, and it sets the price, but throws the > same NULL Pointer on the same line. And after that there are still no > available shares to be bought in the Stock Round Window. > > So the fix did not resolve the problem entirely. (there may be another NULL > Pointer being thrown). I would point it out to you, but a Puppy on my lap is > keeping me from proper debugging mode. > > Mark > > > On Fri, Oct 31, 2008 at 4:11 PM, Erik Vos <eri...@hc...> wrote: > >> Note in the PublicCompany Class, the routine to get the ParPrice, and >> hasParPrice are checking the boolean flag 'hasParPrice. What I really don't >> understand is why have this boolean at all? If the company has a Par Price, >> the variable 'parPrice' will NOT be null. >> >> hasParPrice is a static (not in the java sense) game parameter, set at >> game loading time. It only means: there is a par price that is not >> necessarily equal to the current price. This price does not need to have >> been set yet. One use of hasParPrice is to create an extra"ParPrice" column >> in the Game status, which is absent in games like 1851 that do not have a >> separate par price. >> >> parPrice is 0 until a price has been set. >> >> >> If it is null, than there is no Par Price. Now, if you are trying to use >> the boolean hasParPrice to indicate that the Company is available for >> purchase, then it should be named 'availableForPurchase'. This way you can >> have a "Fixed" Par Price set before you can actually buy the stock. >> >> Yes, but that it not what it means. >> >> But your "fix" to change line 178 to 'if (comp.getParPrice() != null) {' >> moves the test from the PublicCompany Class back out to the setBuyableCerts >> Class which I feel is not right right way to fix it. If you have the >> 'hasParPrice' routine perform the test instead it would be a better >> solution. >> >> Perhaps we need a extra method hasAPriceBeenSet or such. We'll see. >> >> Mark >> >> > |
From: Mark S. <mar...@gm...> - 2008-10-31 21:26:13
|
I ran through a quick test on 1830, and it sets the price, but throws the same NULL Pointer on the same line. And after that there are still no available shares to be bought in the Stock Round Window. So the fix did not resolve the problem entirely. (there may be another NULL Pointer being thrown). I would point it out to you, but a Puppy on my lap is keeping me from proper debugging mode. Mark On Fri, Oct 31, 2008 at 4:11 PM, Erik Vos <eri...@hc...> wrote: > Note in the PublicCompany Class, the routine to get the ParPrice, and > hasParPrice are checking the boolean flag 'hasParPrice. What I really don't > understand is why have this boolean at all? If the company has a Par Price, > the variable 'parPrice' will NOT be null. > > hasParPrice is a static (not in the java sense) game parameter, set at game > loading time. It only means: there is a par price that is not necessarily > equal to the current price. This price does not need to have been set yet. > One use of hasParPrice is to create an extra"ParPrice" column in the Game > status, which is absent in games like 1851 that do not have a separate par > price. > > parPrice is 0 until a price has been set. > > > If it is null, than there is no Par Price. Now, if you are trying to use > the boolean hasParPrice to indicate that the Company is available for > purchase, then it should be named 'availableForPurchase'. This way you can > have a "Fixed" Par Price set before you can actually buy the stock. > > Yes, but that it not what it means. > > But your "fix" to change line 178 to 'if (comp.getParPrice() != null) {' > moves the test from the PublicCompany Class back out to the setBuyableCerts > Class which I feel is not right right way to fix it. If you have the > 'hasParPrice' routine perform the test instead it would be a better > solution. > > Perhaps we need a extra method hasAPriceBeenSet or such. We'll see. > > Mark > > |
From: Erik V. <eri...@hc...> - 2008-10-31 21:11:58
|
Note in the PublicCompany Class, the routine to get the ParPrice, and hasParPrice are checking the boolean flag 'hasParPrice. What I really don't understand is why have this boolean at all? If the company has a Par Price, the variable 'parPrice' will NOT be null. hasParPrice is a static (not in the java sense) game parameter, set at game loading time. It only means: there is a par price that is not necessarily equal to the current price. This price does not need to have been set yet. One use of hasParPrice is to create an extra"ParPrice" column in the Game status, which is absent in games like 1851 that do not have a separate par price. parPrice is 0 until a price has been set. If it is null, than there is no Par Price. Now, if you are trying to use the boolean hasParPrice to indicate that the Company is available for purchase, then it should be named 'availableForPurchase'. This way you can have a "Fixed" Par Price set before you can actually buy the stock. Yes, but that it not what it means. But your "fix" to change line 178 to 'if (comp.getParPrice() != null) {' moves the test from the PublicCompany Class back out to the setBuyableCerts Class which I feel is not right right way to fix it. If you have the 'hasParPrice' routine perform the test instead it would be a better solution. Perhaps we need a extra method hasAPriceBeenSet or such. We'll see. Mark On Fri, Oct 31, 2008 at 3:41 PM, Erik Vos <eri...@hc...> wrote: I have provisionally fixed the bug reported by Mark. Company starts now seem to work again. Over the weekend I will try to rationalise the company price routines. It's indeed a bit of a mess. Erik. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100 <http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/ _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |