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: Erik V. <eri...@hc...> - 2006-02-18 23:30:18
|
> Ok... I've commited some additional changes that return the ORWindow > to fully functioning. I'm now getting a ClassCastException at UpgradesPanel.mouseClicked, line 216, when the first tile is laid. > I'm noticing a bit of flicker in StatusWindow. I'll check and see if > we're painting it too often. I see this flickering only in the part of StatusWindow that overlaps with the StockChart window, and it seems to be caused by excessive repainting of the StockChart, even if nothing has changed there. Erik. |
From: brett l. <wak...@gm...> - 2006-02-18 22:05:26
|
Ok... I've commited some additional changes that return the ORWindow to fully functioning. I'm noticing a bit of flicker in StatusWindow. I'll check and see if we're painting it too often. ---Brett. > > Right now, resizing the ORWindow correctly repaints the window. > Hopefully, I just need to add some more calls to repaint in the right > spots to get the ORWindow fully working again. > |
From: brett l. <wak...@gm...> - 2006-02-15 22:51:08
|
Unfortunately, I haven't had a lot of time in the last week to finish working on this. Currently, all of the underlying methods seem to be working, the only problem is fixing the many repaint/drawing bugs that have crept in during this change. I am going to commit this major change today, despite it not being quite as seamless a change as I wanted it to be. If anyone wants to help squash the repainting bugs before I get to them, they're welcome to jump on in. I'm hoping to get some time this weekend to work on finishing off these changes, if this damned head cold I've got allows me to do anything. A quick overview of what's changed: I've removed all constructor arguments from ORWindow, ORPanel, UpgradesPanel, and any other children of ORWindow. I've reduced the visibility of GameUILoader's copy of MapPanel. There's a suitable get method, but no direct access to mapPanel anymore. I've moved a ton of methods upward from sub-Containers into ORWindow.=20 There's still a few methods that I feel are out of place, and have left comments on some of them, but most of the method placements seem to fit better now. The StatusWindow no longer "owns" the ORWindow. The ORWindow obtains any necessary data from the game model objects rather than from the StatusWindow. Where possible, I've left many of the old sections of code commented out just in case I've pruned too much and something is needed. Right now, resizing the ORWindow correctly repaints the window.=20 Hopefully, I just need to add some more calls to repaint in the right spots to get the ORWindow fully working again. ---Brett. |
From: <sh...@co...> - 2006-02-09 15:18:29
|
I've tried several methods of getting the CSV files off of Sourceforge. 1) Tried the Tortoisecsv - couldn't get it to work. 2) Tried CSV from the command line on my iBook running OS 10.4 - worked fine. 3) Tried the Eclipse on both XP and Mac OS 10.4 - worked fine on both. If one is interested in participating in the project, I'd recommend using Eclipse. If for no other reason than it is what most people seem to be using, and if you run into problems with it, there's a larger pool of people to draw on for help. Steve Haugse |
From: brett l. <wak...@gm...> - 2006-02-08 23:12:55
|
On 2/8/06, Erik Vos <eri...@hc...> wrote: > > The bigger issue that bothers me is that many of these classes have > > constructors that are pulling data from other UI objects. > > > > This strikes me as something that severely breaks model/view > > separation. > > > > For example, the ORWindow shouldn't be passed an OperatingRound, it > > should be checking GameManager for what the current round is, and > > whether it's an OperatingRound. > > That is right, or whether there isn't any round at all yet > (which I believe is true when the window is created). > > > I've been looking at cleaning this up and making ORWindow behave a bit > > more like StockChart, but it's looking like the changes are going to > > be very invasive and require rewriting a bunch of areas of the UI. > > Talking about StockChart: a while ago I was getting pretty annoyed by > double flickering in the StatusWindow after each share Sell or Buy action= . > This turned out to be just the area where StatusWindow overlapped > StockChart. > It looks like if StockChart is fully repainted twice after each action in > StatusWindow, > even if no price has changed at all! > > On this point I would prefer to have StockChart behave more like the othe= r > windows, > where only parts are repainted where and when something has changed. > That would speed up repainting too. We can just stop calling repaint the second time. This should clear up most of the issue. Though, I do agree (and it's even recommended) to not call the no-argument repaint(), but instead call one of the repaint methods with an argument that specifies the region to be repainted. > > The ORWindow constructor is way too complicated as it is, > no doubt it can be simplified. > I am working on it. However, there's a lot of implications to this change that affects many other areas. In short, it's highly invasive. Right now, I've got most of the changes in my local tree, but there's still a lot of things within the ORWindow that have been broken. If you like, I can commit my changes so you can help in reworking the ORWindow, or I can keep working on them privately and commit them after I've gotten more of the ORWindow working. ---Brett |
From: Erik V. <eri...@hc...> - 2006-02-08 22:54:28
|
> The bigger issue that bothers me is that many of these classes have > constructors that are pulling data from other UI objects. > > This strikes me as something that severely breaks model/view > separation. > > For example, the ORWindow shouldn't be passed an OperatingRound, it > should be checking GameManager for what the current round is, and > whether it's an OperatingRound. That is right, or whether there isn't any round at all yet (which I believe is true when the window is created). > I've been looking at cleaning this up and making ORWindow behave a bit > more like StockChart, but it's looking like the changes are going to > be very invasive and require rewriting a bunch of areas of the UI. Talking about StockChart: a while ago I was getting pretty annoyed by double flickering in the StatusWindow after each share Sell or Buy action. This turned out to be just the area where StatusWindow overlapped StockChart. It looks like if StockChart is fully repainted twice after each action in StatusWindow, even if no price has changed at all! On this point I would prefer to have StockChart behave more like the other windows, where only parts are repainted where and when something has changed. That would speed up repainting too. The ORWindow constructor is way too complicated as it is, no doubt it can be simplified. Erik. |
From: Jeffrey B. M. <mc...@br...> - 2006-02-08 14:28:10
|
On Tue, Feb 07, 2006 at 10:47:58PM -0500, Dave Mitton wrote: >=20 > Arggh... I guess that mutates the question to one of the best free=20 > Windows CVS utility? > GUI preferred. Snort. If you don't want one integrated with Eclipse or anything, get http://www.tortoisecvs.org It is a set of shell extensions for Windows. Sourceforge has instructions directly about toroise on its site, also. Jeff --=20 ---------------------------------------------------------------------------- Computer Science is as much about computers as astronomy is about telescopes -- Edsger Wybe Dijkstra (1930-2002) ---------------------------------------------------------------------------- |
From: John A. T. <ja...@ja...> - 2006-02-08 05:59:27
|
On Tue, 7 Feb 2006, Dave Mitton wrote: > Arggh... I guess that mutates the question to one of the best free Windows > CVS utility? > GUI preferred. > > (the system I was trying to load this on already has ClearCase and Perforce) I don't know if those have CVS support, but he mentioned several options earlier in his message. If you are going to be working on Rails, I suggest getting Eclipse installed. I have never tried it on Windows but I can't imagine it would be too difficult. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: Dave M. <da...@mi...> - 2006-02-08 03:50:18
|
On 2/7/2006 10:12 PM, John A. Tamplin wrote: >brett lentz wrote: > >>Or, you can just do a quick n' dirty mass renaming from the command >>line to remove the ",v". >> >That won't compile, since the RCS file format (which is what CVS >uses to store individual files) contains a bunch of meta information >and the entire revision history of the file -- just renaming it >won't change it into a flat java file of the most recent version. > >You really should just use CVS to check it out directly from Sourceforge. > >-- >John A. Tamplin ja...@ja... >770/436-5387 HOME 4116 Manson Ave > Smyrna, GA 30082-3723 Arggh... I guess that mutates the question to one of the best free Windows CVS utility? GUI preferred. (the system I was trying to load this on already has ClearCase and Perforce) Dave. |
From: John A. T. <ja...@ja...> - 2006-02-08 03:08:45
|
brett lentz wrote: >Or, you can just do a quick n' dirty mass renaming from the command >line to remove the ",v". > > That won't compile, since the RCS file format (which is what CVS uses to store individual files) contains a bunch of meta information and the entire revision history of the file -- just renaming it won't change it into a flat java file of the most recent version. You really should just use CVS to check it out directly from Sourceforge. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: brett l. <wak...@gm...> - 2006-02-08 03:05:37
|
That is, in fact, the correct extension because it's just a raw backup of the CVS repository filesystem. For checking the files out of CVS, Sourceforge has a pretty decent how-to written up. Eclipse has a handy CVS plug-in. For Windows, there's WinCVS or the Cygwin utilities as well. Or, you can just do a quick n' dirty mass renaming from the command line to remove the ",v". ---Brett On 2/7/06, Dave Mitton <da...@mi...> wrote: > Guys, > I downloaded your compressed archive, to my XP system, but I didn= 't > have a utility that could handle .bz2 files. > > I got a copy of QuickZip, but it extracted the files into > *.java,v files which don't run well. (yes, the comma and v are in > the file names!) > > What are you using to pack and unpack these files? > > Dave. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Dave M. <da...@mi...> - 2006-02-08 02:42:19
|
Guys, I downloaded your compressed archive, to my XP system, but I didn't have a utility that could handle .bz2 files. I got a copy of QuickZip, but it extracted the files into *.java,v files which don't run well. (yes, the comma and v are in the file names!) What are you using to pack and unpack these files? Dave. |
From: brett l. <wak...@gm...> - 2006-02-08 02:41:18
|
On 2/4/06, Erik Vos <eri...@hc...> wrote: > > I think maybe I'm talking about one thing and meaning another. I > > tossed off that reply rather quickly from work yesterday, so it > > probably didn't get as much thought as I should have put into it. > > > > I realize that we need to track the state of the UI somehow. I'm more > > looking at the organization of the ORWindow. > > > > Right now things are a bit of a mess between HexMap, UpgradePanel, and > > ORWindow. We have HexMap manipulating things in the UpgradePanel, and > > UpgradePanel calling a processDone method in HexMap. > > > > It's all a bit too... incestuous. > > Yes, absolutely. > > > I think that HexMap shouldn't need to know about UpgradePanel, and > > UpgradePanel shouldn't need to know about HexMap. The ORWindow should > > be taking care of governing that when actions are taken, the proper > > information is propagated downward to each Panel that needs affecting. > > ORWindow is a newcomer, so it's not surprising that its role is limited s= o > far. > > I agree that these things can best be controlled form one place, > and I had in fact in mind to choose HexMap for that place, because > that is where the action is as it comes to tile and token laying. > Besides, HexMap is guaranteed to survive whatever UI reorganisation we ma= y > do > in the future. > > ORPanel is another option, as it has the closes ties to the > real state machine in the background: OperatingRound. And ORPanel is > also the place where some of the action buttons are (and I think > we should move the UpgradesPanel buttons there too, opening UpgradePanel > only if there are tiles to show). > > But I have no real objection against using ORWindow. > The bigger issue that bothers me is that many of these classes have constructors that are pulling data from other UI objects. This strikes me as something that severely breaks model/view separation. For example, the ORWindow shouldn't be passed an OperatingRound, it should be checking GameManager for what the current round is, and whether it's an OperatingRound. I've been looking at cleaning this up and making ORWindow behave a bit more like StockChart, but it's looking like the changes are going to be very invasive and require rewriting a bunch of areas of the UI. ---Brett. |
From: Erik V. <eri...@hc...> - 2006-02-05 21:44:20
|
I have committed code that implements an first version of the Game End logic. 1. The broken status of the Bank is detected in the Bank class. 2. GameManager checks at the end of each OR, or at the end of the set of ORs (that is game-dependent) whether the bank has been broken at any time before (Bank.isBroken()). If so, the gameOver flag is set. 3. ORPanel.updateStatus() now checks each time whether the Bank has broken (by calling Bank.isJustBroken()). If true, a pop-up is shown with the message "Bank is broken. The game will be over after the current set of ORs." (this message is of course not applicable in all cases, I will fix that later). 4. ORPanel.updateStatus() now also checks each time when the game has ended by calling GameManager.isGameOver(). If true, a pop-up "GAME OVER" is shown. Further wrapping up (such as displaying the player ranking and stopping the program) still to be done. This is a very simple and not yet complete approach of the game end; we will see if it works or should become a bit more sophisticated. Please note that Bankruptcy is not handled yet. In addition, I have fixed some issues in the ORWindow, such as the disappearing message bar and the not-showing of laid tile and token locations. Erik. |
From: Erik V. <eri...@hc...> - 2006-02-05 20:36:40
|
> > See... I have exactly two problems with the side of the fence the > three of you are on... > > 1. The addCash() method is a part of the CashModel, and not the Bank > object. This means that this boolean is for both breaking the bank AND > triggering forced purchase/sale actions for players. > > 2. This is not how the current code works. We've been value checking > things outside of the container classes for a very long time now. If > you look at Bank, CashModel, and Portfolio, you'll see that none of > them do this. > > I do think that the approach you guys are advocating is a sound > approach AND my changes don't disallow it. In fact, it shouldn't be > difficult to use my change as the first step in building the rest of > the bank breaking mechanism. That is what I am doing now, in fact. Just discovered that the criterion is (or can be) game-dependent, although I have not yet seen cases where "runs out" is not used. (I suppose you have followed the discussion in the 18xx group). I make that the default (so the check will become <0). Erik. |
From: brett l. <wak...@gm...> - 2006-02-05 20:29:42
|
On 2/5/06, ia...@co... <ia...@co...> wrote: > Erik wrote: > > > > > > brett lentz wrote: > > > > > > It sounds like you are suggesting adjustMoney returns a flag and Bank > > > doesn't keep any state that it is broken, so it is up to all > > > the callers > > > to check the return value and propagate that information to anything > > > that needs to know it. Since there are very few places that need to > > > know the bank is broken (which will also need to check other game-end > > > conditions), it seems to make more sense to have the Bank object keep > > > track of whether it is broken and have those few things that > > > care check > > > for it rather than checking after every adjustment to the > > > bank balance. > > > > > > > I agree with John, which is how I would approach it. > > > > We also need a mechanism to inform the user that the bank has > > "just" broken (e.g. via a pop-up). That could be a method that > > returns true exactly once (Bank.isJustBroken()), but that method should > > then be called after every action. It's perhaps easier to have > > the Bank send out an Event or an Observer update call > > (I prefer the latter, as the mechanism is already being used). > > > > Erik. > > I agree, the Bank should make the current balance an observable property.= A 'GameEndMonitor' can then register itself as a listener of that property= of the bank, and if the balance ever goes negative, set the game end flag.= This would allow other game end conditons (e.g. player bankruptcy) to be c= ollected in the same place. You can then easily display the game status ('e= nding after this OR set'), and you don't need to worry about which action c= ould cause the bank-breaking event. > > Iain. > See... I have exactly two problems with the side of the fence the three of you are on... 1. The addCash() method is a part of the CashModel, and not the Bank object. This means that this boolean is for both breaking the bank AND triggering forced purchase/sale actions for players. 2. This is not how the current code works. We've been value checking things outside of the container classes for a very long time now. If you look at Bank, CashModel, and Portfolio, you'll see that none of them do this. I do think that the approach you guys are advocating is a sound approach AND my changes don't disallow it. In fact, it shouldn't be difficult to use my change as the first step in building the rest of the bank breaking mechanism. ---Brett. |
From: <ia...@co...> - 2006-02-05 11:55:02
|
Erik wrote: > > > > brett lentz wrote: > > > > It sounds like you are suggesting adjustMoney returns a flag and Bank > > doesn't keep any state that it is broken, so it is up to all > > the callers > > to check the return value and propagate that information to anything > > that needs to know it. Since there are very few places that need to > > know the bank is broken (which will also need to check other game-end > > conditions), it seems to make more sense to have the Bank object keep > > track of whether it is broken and have those few things that > > care check > > for it rather than checking after every adjustment to the > > bank balance. > > > > I agree with John, which is how I would approach it. > > We also need a mechanism to inform the user that the bank has > "just" broken (e.g. via a pop-up). That could be a method that > returns true exactly once (Bank.isJustBroken()), but that method should > then be called after every action. It's perhaps easier to have > the Bank send out an Event or an Observer update call > (I prefer the latter, as the mechanism is already being used). > > Erik. I agree, the Bank should make the current balance an observable property. A 'GameEndMonitor' can then register itself as a listener of that property of the bank, and if the balance ever goes negative, set the game end flag. This would allow other game end conditons (e.g. player bankruptcy) to be collected in the same place. You can then easily display the game status ('ending after this OR set'), and you don't need to worry about which action could cause the bank-breaking event. Iain. |
From: Erik V. <eri...@hc...> - 2006-02-04 23:40:45
|
> > brett lentz wrote: > > >>Rather than checking it in every place, it seems like it > >>would be better > >>to have the Bank object (or whatever implements the bank) > >>keep track of > >>whether it is broken. Then at the end of an OR you can check > >>that flag > >>and end the game or give a warning message. > >> > >> > > > > > >Who said the return value needs to be checked everywhere? > > > >There are plenty of transactions already happening that don't check > >the return value and won't ever need to. > > > > > If you don't check it, you may miss a case where the bank > breaks. For > example, in one step you pay money from the bank and break > it. If that > one place doesn't check the return value, a later payment to the bank > might hide the fact that the result went negative. > > I am assuming I misunderstand what you intend since otherwise I can't > believe you are arguing this point. > > What I have in mind is a singleton class like this (and I > have no idea > how it is currently implemented): > > public class Bank { > int balance; > boolean broken; > > public Bank(int size) { > balance=size; > broken=false; > } > > public void Bank.adjustMoney(int amount) { > if(balance<amount) { > broken=true; > } > balance-=amount; > } > > public boolean Bank.isBroken() { > return broken; > } > }; > > It sounds like you are suggesting adjustMoney returns a flag and Bank > doesn't keep any state that it is broken, so it is up to all > the callers > to check the return value and propagate that information to anything > that needs to know it. Since there are very few places that need to > know the bank is broken (which will also need to check other game-end > conditions), it seems to make more sense to have the Bank object keep > track of whether it is broken and have those few things that > care check > for it rather than checking after every adjustment to the > bank balance. > I agree with John, which is how I would approach it. We also need a mechanism to inform the user that the bank has "just" broken (e.g. via a pop-up). That could be a method that returns true exactly once (Bank.isJustBroken()), but that method should then be called after every action. It's perhaps easier to have the Bank send out an Event or an Observer update call (I prefer the latter, as the mechanism is already being used). Erik. |
From: John A. T. <ja...@ja...> - 2006-02-04 23:25:57
|
brett lentz wrote: >>Rather than checking it in every place, it seems like it >>would be better >>to have the Bank object (or whatever implements the bank) >>keep track of >>whether it is broken. Then at the end of an OR you can check >>that flag >>and end the game or give a warning message. >> >> > > >Who said the return value needs to be checked everywhere? > >There are plenty of transactions already happening that don't check >the return value and won't ever need to. > > If you don't check it, you may miss a case where the bank breaks. For example, in one step you pay money from the bank and break it. If that one place doesn't check the return value, a later payment to the bank might hide the fact that the result went negative. I am assuming I misunderstand what you intend since otherwise I can't believe you are arguing this point. What I have in mind is a singleton class like this (and I have no idea how it is currently implemented): public class Bank { int balance; boolean broken; public Bank(int size) { balance=size; broken=false; } public void Bank.adjustMoney(int amount) { if(balance<amount) { broken=true; } balance-=amount; } public boolean Bank.isBroken() { return broken; } }; It sounds like you are suggesting adjustMoney returns a flag and Bank doesn't keep any state that it is broken, so it is up to all the callers to check the return value and propagate that information to anything that needs to know it. Since there are very few places that need to know the bank is broken (which will also need to check other game-end conditions), it seems to make more sense to have the Bank object keep track of whether it is broken and have those few things that care check for it rather than checking after every adjustment to the bank balance. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: Erik V. <eri...@hc...> - 2006-02-04 21:47:34
|
> I think maybe I'm talking about one thing and meaning another. I > tossed off that reply rather quickly from work yesterday, so it > probably didn't get as much thought as I should have put into it. > > I realize that we need to track the state of the UI somehow. I'm more > looking at the organization of the ORWindow. > > Right now things are a bit of a mess between HexMap, UpgradePanel, and > ORWindow. We have HexMap manipulating things in the UpgradePanel, and > UpgradePanel calling a processDone method in HexMap. > > It's all a bit too... incestuous. Yes, absolutely. > I think that HexMap shouldn't need to know about UpgradePanel, and > UpgradePanel shouldn't need to know about HexMap. The ORWindow should > be taking care of governing that when actions are taken, the proper > information is propagated downward to each Panel that needs affecting. ORWindow is a newcomer, so it's not surprising that its role is limited so far. I agree that these things can best be controlled form one place, and I had in fact in mind to choose HexMap for that place, because that is where the action is as it comes to tile and token laying. Besides, HexMap is guaranteed to survive whatever UI reorganisation we may do in the future. ORPanel is another option, as it has the closes ties to the real state machine in the background: OperatingRound. And ORPanel is also the place where some of the action buttons are (and I think we should move the UpgradesPanel buttons there too, opening UpgradePanel only if there are tiles to show). But I have no real objection against using ORWindow. Erik. |
From: brett l. <wak...@gm...> - 2006-02-04 19:21:38
|
> > > 4. The tile and token laying steps are now explicitly > > defined (in HexMap), > > > and the messages are directly related to these steps. The > > code is somewhat > > > reorganised around these steps. > > > > > > > I saw this... I'm not sure I completely agree with the > > implementation details. > > > > I think it may be time to move toward using AbstractActions rather > > than static integers to interact with the state of the model. > > Huh? The integers *are* (better: represent) the state > (not of the model but of the UI, see below). > Actions are fine and we already have some. I'm not sure how more > actions would help us, but I'm open to suggestions. > I think maybe I'm talking about one thing and meaning another. I tossed off that reply rather quickly from work yesterday, so it probably didn't get as much thought as I should have put into it. I realize that we need to track the state of the UI somehow. I'm more looking at the organization of the ORWindow. Right now things are a bit of a mess between HexMap, UpgradePanel, and ORWindow. We have HexMap manipulating things in the UpgradePanel, and UpgradePanel calling a processDone method in HexMap. It's all a bit too... incestuous. I think that HexMap shouldn't need to know about UpgradePanel, and UpgradePanel shouldn't need to know about HexMap. The ORWindow should be taking care of governing that when actions are taken, the proper information is propagated downward to each Panel that needs affecting. ---Brett. |
From: brett l. <wak...@gm...> - 2006-02-04 19:06:23
|
On 2/4/06, Erik Vos <eri...@hc...> wrote: > > brett lentz wrote: > > > > >To allow the end game conditions to be detected, I'm changing the > > >return types to various cash transferring methods from void to > > >boolean. > > > > > > > > Rather than checking it in every place, it seems like it > > would be better > > to have the Bank object (or whatever implements the bank) > > keep track of > > whether it is broken. Then at the end of an OR you can check > > that flag > > and end the game or give a warning message. > Who said the return value needs to be checked everywhere? There are plenty of transactions already happening that don't check the return value and won't ever need to. ---Brett. |
From: Erik V. <eri...@hc...> - 2006-02-04 17:08:29
|
> > 1. A new, low line near the top of the OR Window, in which > one-line messages > > are displayed > > about what the player can do at each moment in the game. > Currently, this > > message line > > disappears between token laying and train buying; I don't > understand why, > > but that will no doubt be sorted out in due time. > > > Looks like it doesn't disappear completely, it just gets resized very > very small. Yes, and I think it's because (against my intentions) an empty message is displayed. I will sort it out. > I suspect we may need a more formal layout for the ORWindow than > BoxLayout. As painful as GridBag is to deal with, it provides the > most control. So far BoxLayout looks OK to me. But, if needed, I'm not afraid of GridBagLayout (as used in the other windows). > > 4. The tile and token laying steps are now explicitly > defined (in HexMap), > > and the messages are directly related to these steps. The > code is somewhat > > reorganised around these steps. > > > > I saw this... I'm not sure I completely agree with the > implementation details. > > I think it may be time to move toward using AbstractActions rather > than static integers to interact with the state of the model. Huh? The integers *are* (better: represent) the state (not of the model but of the UI, see below). Actions are fine and we already have some. I'm not sure how more actions would help us, but I'm open to suggestions. Actions and states are different things, I trust I don't need to elaborate on that. What I have done is making the UI-specific states in tile laying more explicit for the immediate purpose of displaying the right prompt. These states are UI-specific because these are not represented in the Model. (All actions in tile laying are provisional until the "Lay Tile" button is pressed; only then the Model is informed. In a future on-line gaming version that would mean, that a player can toy around with the tiles until the decision is made final. Only then will the server and the other players be informed. Does that sound right?) I know that you have approached token laying differently (the Model is informed about all actions). I still believe we should change this approach at some point in time, and so I've nevertheless included the (two) token laying substeps in the UI state 'machine'. Erik. |
From: Erik V. <eri...@hc...> - 2006-02-04 16:12:44
|
> brett lentz wrote: > > >To allow the end game conditions to be detected, I'm changing the > >return types to various cash transferring methods from void to > >boolean. > > > > > Rather than checking it in every place, it seems like it > would be better > to have the Bank object (or whatever implements the bank) > keep track of > whether it is broken. Then at the end of an OR you can check > that flag > and end the game or give a warning message. I agree. Erik. |
From: John A. T. <ja...@ja...> - 2006-02-04 01:18:40
|
brett lentz wrote: >To allow the end game conditions to be detected, I'm changing the >return types to various cash transferring methods from void to >boolean. > > Rather than checking it in every place, it seems like it would be better to have the Bank object (or whatever implements the bank) keep track of whether it is broken. Then at the end of an OR you can check that flag and end the game or give a warning message. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |