rails-devel — List for discussion of Rails development

RE: [Rails-devel] Makings of a JAR

[Erik V. <eri...@hc...>]

> I have no problem running it from a jar with the below command:
> 
> java -classpath 
> \projects\Rails\18xx\rails.jar;\projects\Rails\18xx test.GameTest
> 
> where the second part of the classpath is needed to make 
> LocalisedText.properties visible. 
> I just threw the whole current structure into the jar.
> 
> I cannot pursue this further now, as I am about to leave for 
> a week vacation,
> but I'll send some stuff to Brett separately now.

Sorry, I was too quick: at least the method to find the per-game
subdirectories
does not work this way if I run outside my usual project directory. 
I guess we need to specify the game names in a separate file, 
or sort out how these can be found in the jar in another way.

Brett, if you manage to get it done by whatever trick,
that is fine with me. Otherwise I can start helping you out
when I'm back in a week from now.

Eriuk.

RE: [Rails-devel] Makings of a JAR

[Erik V. <eri...@hc...>]

I have no problem running it from a jar with the below command:

java -classpath \projects\Rails\18xx\rails.jar;\projects\Rails\18xx
test.GameTest

where the second part of the classpath is needed to make
LocalisedText.properties visible.=20
I just threw the whole current structure into the jar.

I cannot pursue this further now, as I am about to leave for a week
vacation,
but I'll send some stuff to Brett separately now.

Erik.

> -----Original Message-----
> From: rai...@li...=20
> [mailto:rai...@li...] On Behalf Of=20
> brett lentz
> Sent: 28 April 2006 00:57
> To: rai...@li...
> Subject: [Rails-devel] Makings of a JAR
>=20
> Over the past couple weeks, I've been pounding my head up against the
> problem of constructing a JAR.
>=20
> The fundamental problem is that resources within a JAR are accessed a
> wee bit differently than they are when they're laying about on the
> local filesystem.
>=20
> I can't seem to find any worthwhile information that tells me how to
> deal with accessing arbitrary files outside of the jar's classpath.
>=20
> So, for the sake of not driving myself insane, the easiest option
> seems to be relocating the /data and /tiles directories to beneath
> /game .
>=20
> If nobody has any alternative methods, as soon as I get my changes
> working, I'll commit 'em.
>=20
> ---Brett.
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

[Rails-devel] Makings of a JAR

[brett l. <wak...@gm...>]

Over the past couple weeks, I've been pounding my head up against the
problem of constructing a JAR.

The fundamental problem is that resources within a JAR are accessed a
wee bit differently than they are when they're laying about on the
local filesystem.

I can't seem to find any worthwhile information that tells me how to
deal with accessing arbitrary files outside of the jar's classpath.

So, for the sake of not driving myself insane, the easiest option
seems to be relocating the /data and /tiles directories to beneath
/game .

If nobody has any alternative methods, as soon as I get my changes
working, I'll commit 'em.

---Brett.

RE: [Rails-devel] Re: Bug: Missing option to trade 4 train for first Diesel at 800$

[Erik V. <eri...@hc...>]

I have fixed some bugs in the train availability area.
The bugs reported did show up in certain circumstances,
but not always, which is why I missed them previously.

I have also fixed a stupid bug that caused all Bank cash
changes to be doubled. It's a miracle that everyone
(including myself) missed that one so far!
It was created when I changed bank cash into an Observed object.

Erik.

> -----Original Message-----
> From: rai...@li...=20
> [mailto:rai...@li...] On Behalf Of Erik Vos
> Sent: 18 April 2006 21:14
> To: rai...@li...
> Subject: RE: [Rails-devel] Re: Bug: Missing option to trade 4=20
> train for first Diesel at 800$
>=20
> I thought this all has worked at some point in time,
> but it is possibly a long time ago that I last tested it....
>=20
> I'll have a look at the bugs that you reported.
>=20
> Erik.=20
>=20
> > -----Original Message-----
> > From: rai...@li...=20
> > [mailto:rai...@li...] On Behalf Of=20
> > brett lentz
> > Sent: 18 April 2006 01:26
> > To: rai...@li...
> > Subject: [Rails-devel] Re: Bug: Missing option to trade 4=20
> > train for first Diesel at 800$
> >=20
> > Correction:  We currently make this available after *all* 6=20
> trains are
> > sold, but the 1830 rules specify that this is supposed to=20
> be available
> > after the *first* 6 train is sold.
> >=20
> > ---Brett.
> >=20
> > On 4/17/06, brett lentz <wak...@gm...> wrote:
> > > In 1830, Once the first 6 train is sold, the option for the
> > > first-buyer discount of trading in a 4-train and $800 for a diesel
> > > needs to be made available.
> > >
> > >
> > > ---Brett.
> > >
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking=20
> > scripting language
> > that extends applications into web and mobile media. Attend=20
> > the live webcast
> > and join the prime developer group breaking into this new=20
> > coding territory!
> > =
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >=20
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

RE: [Rails-devel] End Game Triggers.

[Erik V. <eri...@hc...>]

> > For step 4, I'm thinking of reusing the GameStatus window
> > to do the mandatory share selling, as if it were a special 
> kind of Stock
> > Round.
> > Maybe a subclass of StockRound would work at the Model side.
> >
> 
> 
> Sounds good.  Perhaps for the purposes of clarity in the UI, we should
> only enable buttons specific to the player needing to liquidate so
> that we clearly communicate that the other players can not take any
> stock-related actions.
> 
> Hmm... a subclass of Stockround sounds like it might work. It's a
> StockRound involving only one player with no limit to the number of
> sales that can be made, but buying is disallowed completely.

Yes, that is what I have in mind.

Erik.

Re: [Rails-devel] End Game Triggers.

[brett l. <wak...@gm...>]

> > There's a few things we need for this to work properly:
> >
> > 1. Require a company with no trains to purchase a train.
> > 2. Create a "mandatory train purchase" dialog that informs the user of
> > his required purchase.
> > 3. Include in the "mandatory purchase" dialog a "No Valid Route"
> > button that bypasses the purchase requirement. Companies with no
> > routes to a destination are exempt from the mandatory purchase. This
> > UI should exist until we implement route checking.
> > 4. Add in ability to liquidate assets to purchase train if company's
> > treasury doesn't contain enough money for the purchase.
> > 5. Add in bankruptcy checking if player's total worth is less than the
> > cost of the next available train.
>
> Yes, I agree with all of that.
> For step 4, I'm thinking of reusing the GameStatus window
> to do the mandatory share selling, as if it were a special kind of Stock
> Round.
> Maybe a subclass of StockRound would work at the Model side.
>


Sounds good.  Perhaps for the purposes of clarity in the UI, we should
only enable buttons specific to the player needing to liquidate so
that we clearly communicate that the other players can not take any
stock-related actions.

Hmm... a subclass of Stockround sounds like it might work. It's a
StockRound involving only one player with no limit to the number of
sales that can be made, but buying is disallowed completely.

RE: [Rails-devel] Re: Bug: Missing option to trade 4 train for first Diesel at 800$

[Erik V. <eri...@hc...>]

I thought this all has worked at some point in time,
but it is possibly a long time ago that I last tested it....

I'll have a look at the bugs that you reported.

Erik.=20

> -----Original Message-----
> From: rai...@li...=20
> [mailto:rai...@li...] On Behalf Of=20
> brett lentz
> Sent: 18 April 2006 01:26
> To: rai...@li...
> Subject: [Rails-devel] Re: Bug: Missing option to trade 4=20
> train for first Diesel at 800$
>=20
> Correction:  We currently make this available after *all* 6 trains are
> sold, but the 1830 rules specify that this is supposed to be available
> after the *first* 6 train is sold.
>=20
> ---Brett.
>=20
> On 4/17/06, brett lentz <wak...@gm...> wrote:
> > In 1830, Once the first 6 train is sold, the option for the
> > first-buyer discount of trading in a 4-train and $800 for a diesel
> > needs to be made available.
> >
> >
> > ---Brett.
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

RE: [Rails-devel] End Game Triggers.

[Erik V. <eri...@hc...>]

> It appears that the game-over trigger of breaking the bank works on a
> basic level. I just successfully got the Game Over dialog when I ran
> the bank into negative figures.
> 
> However, no notice is given to the player that the bank has broken,
> and the game will end at the end of the current operating round.
> Ideally, we should remind each player during the beginning of each
> subsequent company's operation phase.
> 
> Also, we aren't currently handling the funds liquidation situations.
> If a player has no trains and not enough money to buy the train
> they've selected, we don't allow him to liquidate stock to generate
> the necessary funds.

Yes, this is one thing I had in mind to start working on.

> There's a few things we need for this to work properly:
> 
> 1. Require a company with no trains to purchase a train.
> 2. Create a "mandatory train purchase" dialog that informs the user of
> his required purchase.
> 3. Include in the "mandatory purchase" dialog a "No Valid Route"
> button that bypasses the purchase requirement. Companies with no
> routes to a destination are exempt from the mandatory purchase. This
> UI should exist until we implement route checking.
> 4. Add in ability to liquidate assets to purchase train if company's
> treasury doesn't contain enough money for the purchase.
> 5. Add in bankruptcy checking if player's total worth is less than the
> cost of the next available train.

Yes, I agree with all of that.
For step 4, I'm thinking of reusing the GameStatus window 
to do the mandatory share selling, as if it were a special kind of Stock
Round. 
Maybe a subclass of StockRound would work at the Model side. 

Erik.

RE: [Rails-devel] Mostly fixes

[Erik V. <eri...@hc...>]

> > One culprit was the ORPanel custom repaint() method,
> > which wiped out everything just written to the grid.
> > I have renamed this method to recreate(), and it is now only called
> > at an OR change. revalidate() now does the repainting job 
> after each action.
> 
> I'd been working on fixing this. However, my preferred solution was to
> store this information in model objects, and then have repaint() pull
> the information from the model.
> 
> Right now, using observables, this data isn't stored anywhere 
> but in the UI.

I would rather say, that it is not stored anywhere else but in the Model,
and pushed from there to the UI....

In fact, you can still switch off the use of Observables by setting
StatusWindow.useObservables to false... except, that the new StockChart
does not (yet) support this mode.

But I think that once we split the code into a server and a client part
(for Internet play), we will have to resort to some kind of server push
(rather than client pull) anyway. Of course, Observer then must be replaced
by something that can bridge the client/server gap.

To be honest, the value push by the Model is done, 
but the View does not yet pick it up that value. 
Instead, once it gets the signal that something has changed,
it pulls the value as it would do on a repaint().
But using the pushed value will be a pretty minor change.
 
Erik.

Re: [Rails-devel] Re: Bug: Missing option to trade 4 train for first Diesel at 800$

[John A. T. <ja...@ja...>]

On Mon, 17 Apr 2006, brett lentz wrote:

> Correction:  We currently make this available after *all* 6 trains are
> sold, but the 1830 rules specify that this is supposed to be available
> after the *first* 6 train is sold.

Actually, the rule is that a Diesel is available for purchase as soon as a 
6 is purchased.  Separately, a Diesel may be purchased for $1100 cash or 
$800 with a trade-in of any train (which can be a 4 that is about to go 
away, or any other train including another Diesel).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

[Rails-devel] Re: Bug: Missing option to trade 4 train for first Diesel at 800$

[brett l. <wak...@gm...>]

Correction:  We currently make this available after *all* 6 trains are
sold, but the 1830 rules specify that this is supposed to be available
after the *first* 6 train is sold.

---Brett.

On 4/17/06, brett lentz <wak...@gm...> wrote:
> In 1830, Once the first 6 train is sold, the option for the
> first-buyer discount of trading in a 4-train and $800 for a diesel
> needs to be made available.
>
>
> ---Brett.
>

[Rails-devel] Bug: Missing option to trade 4 train for first Diesel at 800$

[brett l. <wak...@gm...>]

In 1830, Once the first 6 train is sold, the option for the
first-buyer discount of trading in a 4-train and $800 for a diesel
needs to be made available.


---Brett.

[Rails-devel] End Game Triggers.

[brett l. <wak...@gm...>]

It appears that the game-over trigger of breaking the bank works on a
basic level. I just successfully got the Game Over dialog when I ran
the bank into negative figures.

However, no notice is given to the player that the bank has broken,
and the game will end at the end of the current operating round.
Ideally, we should remind each player during the beginning of each
subsequent company's operation phase.

Also, we aren't currently handling the funds liquidation situations.
If a player has no trains and not enough money to buy the train
they've selected, we don't allow him to liquidate stock to generate
the necessary funds.

There's a few things we need for this to work properly:

1. Require a company with no trains to purchase a train.
2. Create a "mandatory train purchase" dialog that informs the user of
his required purchase.
3. Include in the "mandatory purchase" dialog a "No Valid Route"
button that bypasses the purchase requirement. Companies with no
routes to a destination are exempt from the mandatory purchase. This
UI should exist until we implement route checking.
4. Add in ability to liquidate assets to purchase train if company's
treasury doesn't contain enough money for the purchase.
5. Add in bankruptcy checking if player's total worth is less than the
cost of the next available train.


---Brett.

[Rails-devel] Bug: Cancel setting purchase price doesn't cancel purchase

[brett l. <wak...@gm...>]

Found a bug:

When buying a train, if you select to buy a train from another
company, and then hit Cancel out of the "Set Purchase Price" dialog,
the purchase is not cancelled. Instead, the purchase is pushed through
at the train's default price.

The correct behavior should be that Cancelling the purchase price
dialog should cancel the whole transaction.

---Brett.

Re: [Rails-devel] Mostly fixes

[brett l. <wak...@gm...>]

On 4/17/06, Erik Vos <eri...@hc...> wrote:
>
> It's been a while, but over the Easter weekend I've finally
> managed to do some work on our beloved project.
>

YAY!  :-)

> I had planned to start with some new functionality, but in an
> initial test to see where we are I found quite some bugs in the OR GUI.

Yeah, many of these are my fault and were introduced in the
reorganization of the OR classes.

> One culprit was the ORPanel custom repaint() method,
> which wiped out everything just written to the grid.
> I have renamed this method to recreate(), and it is now only called
> at an OR change. revalidate() now does the repainting job after each acti=
on.

I'd been working on fixing this. However, my preferred solution was to
store this information in model objects, and then have repaint() pull
the information from the model.

Right now, using observables, this data isn't stored anywhere but in the UI=
.


> I have tried to streamline the interactions between the various OR
> components
> such that the whole is a bit more robust now. But no guarantees.
> So far it has more than once turned out that such attempts have made
> things worse rather than better....
>

I've poked a little at the new code, it seems to restore everything to
working order. So far, I've found no major issues.


> The improvements include:
>
> - The most recent revenue figure is now remembered and displayed
> across OR's. For this, I have created a new MoneyModel class, into
> which I also expect to merge some other money-related granular "model"
> classes later.
>

Good, this will help in developing end-game stats.

> - The Stock chart squares are now separate objects (new class GUIStockSpa=
ce)
> which observe the model's StockSpace changes. The whole stock chart
> is now no longer completely recreated at each share action, as it was
> before.
> Just the affected squares are redrawn.

Excellent.  I knew this would be necessary...

>
> - After the above change the overlapping part between StatusWindow
> and StockChart still showed the annoying flickering. This turned out
> to be caused by the setVisible(true) call for the Stock Chart after
> each action in the StatusWindow. I have changed this so that setVisible
> for any window is now only called at the start of a new round.
>
> It seems to me, that the GUI is now in a somewhat better shape,
> although still far from perfect.
>

IMO, it's looking good.  I don't think we're missing any important
data that the user should see.


I still need to double-check the end-game code and see if we handle
that correctly.  If that works, I'll see about bundling up a JAR for
wider consumption/testing.


----Brett.

[Rails-devel] Mostly fixes

[Erik V. <eri...@hc...>]

It's been a while, but over the Easter weekend I've finally
managed to do some work on our beloved project.

I had planned to start with some new functionality, but in an
initial test to see where we are I found quite some bugs in the OR GUI. 
To name a few:
- information just written to the ORPanel disappeared almost
immediately;
- upgrades kept being displayed after tile laying;
- pressing Done only showed effect after the ORWindow was resized.

It took all my time to get this all fixed (including the usual new errors 
caused by my own fixes) and add a few improvements.

One culprit was the ORPanel custom repaint() method,
which wiped out everything just written to the grid. 
I have renamed this method to recreate(), and it is now only called
at an OR change. revalidate() now does the repainting job after each action.

I have tried to streamline the interactions between the various OR
components
such that the whole is a bit more robust now. But no guarantees.
So far it has more than once turned out that such attempts have made
things worse rather than better....

The improvements include:

- The most recent revenue figure is now remembered and displayed
across OR's. For this, I have created a new MoneyModel class, into
which I also expect to merge some other money-related granular "model"
classes later.

- The Stock chart squares are now separate objects (new class GUIStockSpace)
which observe the model's StockSpace changes. The whole stock chart
is now no longer completely recreated at each share action, as it was
before.
Just the affected squares are redrawn.

- After the above change the overlapping part between StatusWindow
and StockChart still showed the annoying flickering. This turned out
to be caused by the setVisible(true) call for the Stock Chart after
each action in the StatusWindow. I have changed this so that setVisible
for any window is now only called at the start of a new round.

It seems to me, that the GUI is now in a somewhat better shape,
although still far from perfect. 

One thing I would like to add pretty soon is a display of coordinates
(like A1, B2) on both the map and the stock chart.

Erik.

Re: [Rails-devel] Bug in Changing Rounds

[brett l. <wak...@gm...>]

Oh... And I've also just fixed a bug causing the scrollpane to screw
with hex selection.

---Brett.


On 3/22/06, brett lentz <wak...@gm...> wrote:
> K... no worries. We'll be here when ya return.  :-)
>
>
> I found the round transitioning bug and fixed it. I've also fixed the
> repainting of the ORPanel, so now it's no longer got the artifacts in
> some cells.
>
> ---Brett.
>
>
> On 3/21/06, Erik Vos <eri...@hc...> wrote:
> > I have been silent too for quite a while,
> > and that will stay so in the next few weeks.
> > I'll try to be back in April.
> > Erik.
> >
> > > -----Original Message-----
> > > From: rai...@li...
> > > [mailto:rai...@li...] On Behalf Of
> > > brett lentz
> > > Sent: 21 March 2006 23:18
> > > To: rai...@li...
> > > Subject: [Rails-devel] Bug in Changing Rounds
> > >
> > > I've finally gotten some time to work on Rails again.
> > >
> > > I've fixed a bug in ORPanel that was causing the rounds to not
> > > transition back to a Stock Round when the Done button was clicked.
> > >
> > > However, this is only a partial fix because now, the buttons on the
> > > StatusWindow is not being enabled correctly to allow the Stock Round
> > > to proceed.
> > >
> > > ---Brett.
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking
> > > scripting language
> > > that extends applications into web and mobile media. Attend
> > > the live webcast
> > > and join the prime developer group breaking into this new
> > > coding territory!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=12164=
2
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> > that extends applications into web and mobile media. Attend the live we=
bcast
> > and join the prime developer group breaking into this new coding territ=
ory!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>

Re: [Rails-devel] Bug in Changing Rounds

[brett l. <wak...@gm...>]

K... no worries. We'll be here when ya return.  :-)


I found the round transitioning bug and fixed it. I've also fixed the
repainting of the ORPanel, so now it's no longer got the artifacts in
some cells.

---Brett.


On 3/21/06, Erik Vos <eri...@hc...> wrote:
> I have been silent too for quite a while,
> and that will stay so in the next few weeks.
> I'll try to be back in April.
> Erik.
>
> > -----Original Message-----
> > From: rai...@li...
> > [mailto:rai...@li...] On Behalf Of
> > brett lentz
> > Sent: 21 March 2006 23:18
> > To: rai...@li...
> > Subject: [Rails-devel] Bug in Changing Rounds
> >
> > I've finally gotten some time to work on Rails again.
> >
> > I've fixed a bug in ORPanel that was causing the rounds to not
> > transition back to a Stock Round when the Done button was clicked.
> >
> > However, this is only a partial fix because now, the buttons on the
> > StatusWindow is not being enabled correctly to allow the Stock Round
> > to proceed.
> >
> > ---Brett.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking
> > scripting language
> > that extends applications into web and mobile media. Attend
> > the live webcast
> > and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

RE: [Rails-devel] Bug in Changing Rounds

[Erik V. <eri...@hc...>]

I have been silent too for quite a while,
and that will stay so in the next few weeks.
I'll try to be back in April.
Erik.=20

> -----Original Message-----
> From: rai...@li...=20
> [mailto:rai...@li...] On Behalf Of=20
> brett lentz
> Sent: 21 March 2006 23:18
> To: rai...@li...
> Subject: [Rails-devel] Bug in Changing Rounds
>=20
> I've finally gotten some time to work on Rails again.
>=20
> I've fixed a bug in ORPanel that was causing the rounds to not
> transition back to a Stock Round when the Done button was clicked.
>=20
> However, this is only a partial fix because now, the buttons on the
> StatusWindow is not being enabled correctly to allow the Stock Round
> to proceed.
>=20
> ---Brett.
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

[Rails-devel] Bug in Changing Rounds

[brett l. <wak...@gm...>]

I've finally gotten some time to work on Rails again.

I've fixed a bug in ORPanel that was causing the rounds to not
transition back to a Stock Round when the Done button was clicked.

However, this is only a partial fix because now, the buttons on the
StatusWindow is not being enabled correctly to allow the Stock Round
to proceed.

---Brett.

Re: [Rails-devel] Re: Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

On 2/23/06, Erik Vos <eri...@hc...> wrote:
> > I've fixed the bug.  It looks like it was due to me being a little
> > over-zealous and commenting some necessary methods.
>
> I've also found a fix, but a different one (you have re-enabled
> some redundant methods that I had removed - and in fact replaced
> - which did the job in the old way).
>

Ok... I thought I may have disabled them when I was mucking about with ORWi=
ndow.

Go ahead and remove them, and put in your new fix.


> However, when testing my fix it I noticed that SR2 does no longer start
> properly.
> SR2 is announced, but the GameStatus panel does not change in any way,
> disallowing any user action.
>
> I have now undone my changes, but SR2 still does not start.
> So it looks there is a problem with your recent changes.
> What do you see in SR2?
>


I'll test this shortly.

---Brett.

RE: [Rails-devel] Re: Separation of ORWindow Dependencies.

[Erik V. <eri...@hc...>]

> I've fixed the bug.  It looks like it was due to me being a little
> over-zealous and commenting some necessary methods.

I've also found a fix, but a different one (you have re-enabled
some redundant methods that I had removed - and in fact replaced=20
- which did the job in the old way).=20

However, when testing my fix it I noticed that SR2 does no longer start
properly.=20
SR2 is announced, but the GameStatus panel does not change in any way,=20
disallowing any user action.

I have now undone my changes, but SR2 still does not start.
So it looks there is a problem with your recent changes.
What do you see in SR2?

Erik.

>=20
> ---Brett.
>=20
>=20
> On 2/21/06, brett lentz <wak...@gm...> wrote:
> > I'm seeing a bug in StatusWindow where after buying out 100% of the
> > company, the selector button remains at 10%.
> >
> >
> > ----Brett.
> >
> >
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>=20
>=20

Re: [Rails-devel] Re: Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

I've fixed the bug.  It looks like it was due to me being a little
over-zealous and commenting some necessary methods.

---Brett.


On 2/21/06, brett lentz <wak...@gm...> wrote:
> I'm seeing a bug in StatusWindow where after buying out 100% of the
> company, the selector button remains at 10%.
>
>
> ----Brett.
>
>
>

Re: [Rails-devel] Re: Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

I'm seeing a bug in StatusWindow where after buying out 100% of the
company, the selector button remains at 10%.


----Brett.



On 2/20/06, brett lentz <wak...@gm...> wrote:
> On 2/18/06, Erik Vos <eri...@hc...> wrote:
> > > Ok...  I've commited some additional changes that return the ORWindow
> > > to fully functioning.
> >
> > I'm now getting a ClassCastException at UpgradesPanel.mouseClicked, lin=
e
> > 216,
> > when the first tile is laid.
> >
>
> OK... Fixed that.
>
>

Re: [Rails-devel] Re: Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

On 2/18/06, Erik Vos <eri...@hc...> wrote:
> > 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.
>

OK... Fixed that.


> > 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.
>

I've committed some initial changes to StockChart that lay the
groundwork for fixing this.

Essentially the problem is that, with every repaint, we're removing
all elements of the StockChart, and repopulating the whole thing.

So, I'm having to rework a bit of the structure of StockChart to allow
us to update a single element of the chart without having to
repopulate the whole thing.


----Brett.