rails-devel — List for discussion of Rails development

RE: [Rails-devel] OR updates

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

> > What we need is some kind of messages from the Model to the View
> > about changes of individual values that have taken place 
> > and (possibly) need be reflected in the UI.
> 
> I think you should revisit how we accomplished this for the 
> StockChart.  In StockChart, we just call repaint() whenever 
> the model changes. I don't think there's any good reason why 
> ORWindow needs to be any different.

In fact, we call refreshStockPanel(), which completely
rebuilds the stock chart.
 
> We don't need any sort of messaging subsystem if painting is 
> *only* dealing with drawing the objects that represent the 
> model as efficiently as possible. We can call repaint() as 
> often as we need to.

But we don't.

> So far, the painting code hasn't shown any indication that 
> it's too slow to be repeatedly repainted.

Maybe not.

But I wonder how this all would work out in a distributed environment.
If the server would only send a message to all clients to have them all 
completely rebuild themselves, that will cause a lot of calls to the server!

It seems to me that atomic update messages from server to client
would do a more efficient job.

Now I don't know for sure if Observer/Observable plus RMI would do that job,
but I think it has a good chance.

Erik.

RE: [Rails-devel] OR updates

[Brett L. <wak...@ea...>]

> What we need is some kind of messages from the Model to the View
> about changes of individual values that have taken place 
> and (possibly) need be reflected in the UI.

I think you should revisit how we accomplished this for the StockChart.  In StockChart, we just call repaint() whenever the model changes. I don't think there's any good reason why ORWindow needs to be any different.

We don't need any sort of messaging subsystem if painting is *only* dealing with drawing the objects that represent the model as efficiently as possible. We can call repaint() as often as we need to.

So far, the painting code hasn't shown any indication that it's too slow to be repeatedly repainted.

---Brett.

RE: [Rails-devel] OR updates

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

> I think this would be much simpler a task if we merged 
> ORWindow with MapWindow into a single JFrame, much like 
> StatusWindow is a collection of multiple JPanels within a 
> single JFrame.  This merger would also make our overall UI 
> much simpler and more approachable for end-users. 

Could be, but that is a separate issue.
 
> Also, instead of Observers/Observables, would it be possible 
> to just add new methods to the model-side to help simplify 
> the bounds checking that we need to do to allow these behaviors?
> 
> Or is it that the OR is significantly complicated that the 
> methods we used in StatusWindow won't work for the ORWindow?

The problem is, that many actions in the OR cause changes
in both the OR and the Status window.

My point is, that I do not want to redraw both windows entirely 
after each action, because it slows down and makes the UI clunky.
Therefore I have so far created lots of methods in both classes
that all update part of a screen, and are called from within ORWindow.
IMO that is becoming unwieldy.

What we need is some kind of messages from the Model to the View
about changes of individual values that have taken place 
and (possibly) need be reflected in the UI.

Our rules forbid direct calls, but I suppose a registration-based
interface might be acceptable. IMO Events are too heavy.

I'm not yet planning a complete overhaul, just an experiment.

Erik.

Re: [Rails-devel] OR updates

[Brett L. <wak...@ea...>]

I think this would be much simpler a task if we merged ORWindow with MapWindow into a single JFrame, much like StatusWindow is a collection of multiple JPanels within a single JFrame.  This merger would also make our overall UI much simpler and more approachable for end-users. 

Also, instead of Observers/Observables, would it be possible to just add new methods to the model-side to help simplify the bounds checking that we need to do to allow these behaviors?

Or is it that the OR is significantly complicated that the methods we used in StatusWindow won't work for the ORWindow?


---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Dec 7, 2005 2:45 PM
To: rai...@li...
Subject: [Rails-devel] OR updates

I have restarted working on the OR.

This will include incorporating token laying,
but I have started with some general improvements,
such as skipping or automatically processing steps
where the player has no options:
- the token step, if the company has no free tokens left,
- the revenue step, if the company has no trains, so the revenue is zero.
- the train buying step, if there is no room for new trains.

However, this turns out to make the task to keep the SR and OR 
windows up to date even more complicated, so I am now seriously 
considering to replace the current mechanisms by implementing
the Observer/Observable pattern.
That will be quite some work, but should very much
simplify the updating task when we continue adding features.

Erik.

[Rails-devel] OR updates

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

I have restarted working on the OR.

This will include incorporating token laying,
but I have started with some general improvements,
such as skipping or automatically processing steps
where the player has no options:
- the token step, if the company has no free tokens left,
- the revenue step, if the company has no trains, so the revenue is zero.
- the train buying step, if there is no room for new trains.

However, this turns out to make the task to keep the SR and OR 
windows up to date even more complicated, so I am now seriously 
considering to replace the current mechanisms by implementing
the Observer/Observable pattern.
That will be quite some work, but should very much
simplify the updating task when we continue adding features.

Erik.

RE: [Rails-devel] More Token Laying Code is in CVS.

[Brett L. <wak...@ea...>]

> I still suspect that we will need Station (or City) objects as a 
> bridge between MapHex and Token objects. But first I'm curious 
> to see what John has on offer regarding Tile objects.

This is how I've handled it.  The Station list is copied from Tile to MapHex each time the Tile is upgraded. The Token list is merged when necessary, and moved to the new Station list for each Tile upgrade.


---Brett

RE: [Rails-devel] More Token Laying Code is in CVS.

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

> Just in time for the weekend, I've just committed a fairly 
> sizable amount of the token laying code into CVS.
> 
> I've got the initial groundwork built for drawing tokens in 
> semi-correct positions based on number of stations in the hex 
> and number of tokens in the hex.  Most of what's left here is 
> the rather tedious task of finding reasonable coordinate offsets.
> 
> As far as I can tell, tokens are being properly distributed 
> and assigned. Testing this is somewhat tedious, but the 
> inital home tokens are being placed where they should be.
> 
> I think it's ready, or very close to being ready, for hooking 
> up to the OR Window to allow manual token laying.  Erik, did 
> you want to handle that area, or did you want me to take a stab at it?

If you feel like trying that, OK with me, otherwise I will happily 
pick it up later. I'm a bit busy now with other matters, 
so it may take a few days before I'll become active again.
 
> Here's the more important changes:
> 
> Company now has it's own overridden equals() method for 
> comparing two CompanyI objects and returning a boolean 
> indicating whether they're the same object or not.

> Company now has it's own toString() method for obtaining 
> quick n' dirty information about the particular object.
> 
> MapHexes now maintain an instance of the PublicCompany that 
> has a home or destination in that particular hex. I added 
> this mostly because it makes more sense to compare company 
> objects rather than just their name strings.

All good stuff.

> MapHex has an initial stab at merging token lists. I haven't 
> tested it at all yet, and it currently only handles merging 
> down to a single station from N number of stations.  Looking 
> through the tile images, I couldn't find a tile that 
> indicated that three stations ever merged into two, so I 
> don't think any additional merge code needs to be added to 
> handle that situation. I could be wrong.

I still suspect that we will need Station (or City) objects as a 
bridge between MapHex and Token objects. But first I'm curious 
to see what John has on offer regarding Tile objects.

Erik.

[Rails-devel] More Token Laying Code is in CVS.

[Brett L. <wak...@ea...>]

Just in time for the weekend, I've just committed a fairly sizable amount of the token laying code into CVS.

I've got the initial groundwork built for drawing tokens in semi-correct positions based on number of stations in the hex and number of tokens in the hex.  Most of what's left here is the rather tedious task of finding reasonable coordinate offsets.

As far as I can tell, tokens are being properly distributed and assigned. Testing this is somewhat tedious, but the inital home tokens are being placed where they should be.

I think it's ready, or very close to being ready, for hooking up to the OR Window to allow manual token laying.  Erik, did you want to handle that area, or did you want me to take a stab at it?

Here's the more important changes:

Company now has it's own overridden equals() method for comparing two CompanyI objects and returning a boolean indicating whether they're the same object or not.

Company now has it's own toString() method for obtaining quick n' dirty information about the particular object.

MapHexes now maintain an instance of the PublicCompany that has a home or destination in that particular hex. I added this mostly because it makes more sense to compare company objects rather than just their name strings.

MapHex has an initial stab at merging token lists. I haven't tested it at all yet, and it currently only handles merging down to a single station from N number of stations.  Looking through the tile images, I couldn't find a tile that indicated that three stations ever merged into two, so I don't think any additional merge code needs to be added to handle that situation. I could be wrong.

I think for anything else that's important, I've left comments in the code.


---Brett.

RE: [Rails-devel] Initial Token Laying is in CVS.

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

> That won't be as much of a problem, the bigger issue is 
> whether I need to worry about splits AND merges or just merges.

I'm not aware of any splits. We can forget about these.

Erik.

Re: [Rails-devel] Initial Token Laying is in CVS.

[Brett L. <wak...@ea...>]

> I am not sure how that fits in with your plans, or how different that is 
> than having the Hex object perform the same function.

We have both Hex and Tile objects.  There were multiple reasons that these needed to be split.

Hex (or, more properly, MapHex) refers to the hex as it is on the game map, and Tile refers to any generic hex tile on or off the map.  MapHexes contain Tiles, among other things. 

The bit that I'm mentioning has changed is that both Tiles and MapHexes will now have Station objects. Again, one will refer to active in-game elements, and the other will be elements that exist on and off the board.

The important piece is that Tokens should only be assigned to the Stations on the MapHex, and never assigned to the Station on the Tile.

> There are games where there is a token-city and a whistlestop on one tile, 
> and as it upgrades the whistlestop becomes a separate city and eventually 
> merges into the main city.

That won't be as much of a problem, the bigger issue is whether I need to worry about splits AND merges or just merges.


---Brett

Re: [Rails-devel] Initial Token Laying is in CVS.

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

On Wed, 30 Nov 2005, Brett Lentz wrote:

> Hexes will maintain a copy of the Tile's station list. The hex station 
> list will hold the tokens. The tile's station list can't hold tokens 
> because otherwise every -11 tile shows up with the same token in it (i 
> tried it this way first ;-).
>
> So, that means whenever tiles are upgraded we have to fuss about with 
> comparing the new station list with the current list and shuffling 
> tokens from one list to the other.  However, I can't really see any 
> other way of handling this more gracefully.

How I had envisioned it was that particular tiles laid on the map would be 
TileInstance objects, which referred to the underlying Tile object for 
drawing etc, but kept its own information for upgrade costs (such as games 
like 18EU where after you pay a build cost for yellow, you then need to 
pay a build cost for green while still using standard tiles), tokens, and 
anything else appropriate to the particular hex it was played on.

I am not sure how that fits in with your plans, or how different that is 
than having the Hex object perform the same function.

> The worst of it is really going to be merging the lists when a tile with 
> multiple stations upgrades to a tile with a single station.  I haven't 
> done this yet, but it doesn't seem like it'll be too painful.
>
> I can't think of any situation where a tile with a single station ever 
> upgrades into a tile with multiple stations. If these exist, please 
> speak up.

There are games where there is a token-city and a whistlestop on one tile, 
and as it upgrades the whistlestop becomes a separate city and eventually 
merges into the main city.

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

[Rails-devel] Initial Token Laying is in CVS.

[Brett L. <wak...@ea...>]

The inital bits of Token laying are now in CVS.

Right now, only the home token is being played, and only to the center of the hex. Obviously this is kind of ugly in some situations, but it'll improve as we go along.  Manually playing tokens is not yet coded.  There's also quite a few other details of token laying that aren't yet complete.

To cope with multi-station tiles, here's what I've done:

Hexes will maintain a copy of the Tile's station list. The hex station list will hold the tokens. The tile's station list can't hold tokens because otherwise every -11 tile shows up with the same token in it (i tried it this way first ;-).

So, that means whenever tiles are upgraded we have to fuss about with comparing the new station list with the current list and shuffling tokens from one list to the other.  However, I can't really see any other way of handling this more gracefully.

The worst of it is really going to be merging the lists when a tile with multiple stations upgrades to a tile with a single station.  I haven't done this yet, but it doesn't seem like it'll be too painful.

I can't think of any situation where a tile with a single station ever upgrades into a tile with multiple stations. If these exist, please speak up.


---Brett

[Rails-devel] Bug in tile rotation.

[Brett L. <wak...@ea...>]

There's a bug in the tile rotation logic.

If you play tile 56 on hex F20 of the 1830 map and try to rotate it, you'll see that it doesn't allow you to rotate through all valid rotations.


---Brett.

RE: [Rails-devel] Re: HELP

[Brett L. <wak...@ea...>]

I understand, and to some extent agree.

I think it's sufficient to provide help on the current round. Context-sensitive help is nice, but really not necessary.  

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 30, 2005 6:30 PM
To: rai...@li...
Subject: RE: [Rails-devel] Re: HELP

At the moment, the game and game-state dependency of the help texts 
concerns me a lot more than internationalization.

At one point I thought about creating a HTML file per game step,
each one being a template to be run through a formatter to replace 
variables by real data (such as OR number, player/company turn etc.).
This could (of course) be a file per language.

But there seems to be too much variability between games to make
this an easy approach. 
We would end up with a file per game, game step and language,
and even then we would need some trickery to handle phase-dependent info
(such as that mentioning the option to buy privates in 1830
should only show up in the green phase).

Perhaps my original goal to exactly describe all currently available 
options at every point in time is too optimistic.

Anyway, the only point I was trying to make so far is, 
that the help displayed by the UI must be provided somehow
by the currently active Round subclass.
That 'somehow' now consists of full HTML text, but it might well
become some language-independent Help class, or just an array
of resource bundle keys, that would be turned into language-dependent 
HTML by the GUI (possibly a different language per player).

Just thinking aloud.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> John A. Tamplin
> Sent: 30 November 2005 23:36
> To: rai...@li...
> Subject: Re: [Rails-devel] Re: HELP
> 
> On Wed, 30 Nov 2005, Brett Lentz wrote:
> 
> > While I don't (yet) want to completely 
> internationalize/localize the 
> > code, it is good to be aware of how Java approaches this and make a 
> > future move a bit less cumbersome.
> >
> > Also, regardless of the implementation, my bigger concern is that 
> > maintaining a help system that is intertwined with the code is 
> > excessively cumbersome and ought to be avoided by 
> everything but the 
> > earliest stages of development.
> 
> Using a catalog-based internationalization system gets you 
> that for free.
> As he mentioned, the tricky bit is handling cases where the order of
> dynamically generated items or even their presentation can change.
> 
> I have always found it easier to use the message catalogs from the 
> beginning rather than trying to retrofit them in after the project is 
> almost done.  Once you get the base infrastructure setup, it 
> really isn't
> much more work to use it than just putting strings straight 
> into the code.
> 
> -- 
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                  		 		Smyrna, GA  30082-3723
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Re: HELP

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

At the moment, the game and game-state dependency of the help texts 
concerns me a lot more than internationalization.

At one point I thought about creating a HTML file per game step,
each one being a template to be run through a formatter to replace 
variables by real data (such as OR number, player/company turn etc.).
This could (of course) be a file per language.

But there seems to be too much variability between games to make
this an easy approach. 
We would end up with a file per game, game step and language,
and even then we would need some trickery to handle phase-dependent info
(such as that mentioning the option to buy privates in 1830
should only show up in the green phase).

Perhaps my original goal to exactly describe all currently available 
options at every point in time is too optimistic.

Anyway, the only point I was trying to make so far is, 
that the help displayed by the UI must be provided somehow
by the currently active Round subclass.
That 'somehow' now consists of full HTML text, but it might well
become some language-independent Help class, or just an array
of resource bundle keys, that would be turned into language-dependent 
HTML by the GUI (possibly a different language per player).

Just thinking aloud.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> John A. Tamplin
> Sent: 30 November 2005 23:36
> To: rai...@li...
> Subject: Re: [Rails-devel] Re: HELP
> 
> On Wed, 30 Nov 2005, Brett Lentz wrote:
> 
> > While I don't (yet) want to completely 
> internationalize/localize the 
> > code, it is good to be aware of how Java approaches this and make a 
> > future move a bit less cumbersome.
> >
> > Also, regardless of the implementation, my bigger concern is that 
> > maintaining a help system that is intertwined with the code is 
> > excessively cumbersome and ought to be avoided by 
> everything but the 
> > earliest stages of development.
> 
> Using a catalog-based internationalization system gets you 
> that for free.
> As he mentioned, the tricky bit is handling cases where the order of
> dynamically generated items or even their presentation can change.
> 
> I have always found it easier to use the message catalogs from the 
> beginning rather than trying to retrofit them in after the project is 
> almost done.  Once you get the base infrastructure setup, it 
> really isn't
> much more work to use it than just putting strings straight 
> into the code.
> 
> -- 
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                  		 		Smyrna, GA  30082-3723
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] Re: HELP

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

On Wed, 30 Nov 2005, Brett Lentz wrote:

> While I don't (yet) want to completely internationalize/localize the 
> code, it is good to be aware of how Java approaches this and make a 
> future move a bit less cumbersome.
>
> Also, regardless of the implementation, my bigger concern is that 
> maintaining a help system that is intertwined with the code is 
> excessively cumbersome and ought to be avoided by everything but the 
> earliest stages of development.

Using a catalog-based internationalization system gets you that for free.
As he mentioned, the tricky bit is handling cases where the order of
dynamically generated items or even their presentation can change.

I have always found it easier to use the message catalogs from the 
beginning rather than trying to retrofit them in after the project is 
almost done.  Once you get the base infrastructure setup, it really isn't
much more work to use it than just putting strings straight into the code.

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

Re: [Rails-devel] Re: HELP

[Brett L. <wak...@ea...>]

See my reply to John in which I reference that same tutorial.  ;-)

While I don't (yet) want to completely internationalize/localize the code, it is good to be aware of how Java approaches this and make a future move a bit less cumbersome.

Also, regardless of the implementation, my bigger concern is that maintaining a help system that is intertwined with the code is excessively cumbersome and ought to be avoided by everything but the earliest stages of development.


---Brett.

-----Original Message-----
From: ia...@co...
Sent: Nov 30, 2005 5:02 PM
To: rai...@li...
Subject: [Rails-devel] Re: HELP

>> Subject: RE: [Rails-devel] Help
>> 
>> I just had a chance to look at the help system a little more in-depth.
>> 
>> >At some point we're going to want to separate the text strings from the code.  >Perhaps we should generate a global help xml file to hold the text, or maybe a >help directory to hold multiple files, and then also have a game->specific help file for including any game-specific help information.

You need to read up on internationalization (aka I18N) and localization (aka L10N). Basically your code ends up referring to property names, which are then looked up in property files for the actual text. Different versions of the props file(s) are provided for each locale, and the user's settings determine which one is used.

ISTR the tutorial trail on Suns's Java website explaining the process covered it very nicely, and didn't take long to read. I internationalised a small app in about couple of hours, including reading the tutorial. There's also an Eclipse wizard which helps configure it all for you.

I'd advise having a small number of files, probably only one for the base 
application, rather than one per package (which is the alternative). Also make sure you use Format strings where appropriate so that you can cope with parameters (e.g. company name, currency refs, etc) being in different places in the text in different languages.

Iain.





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Re: HELP

[<ia...@co...>]

>> Subject: RE: [Rails-devel] Help
>> 
>> I just had a chance to look at the help system a little more in-depth.
>> 
>> >At some point we're going to want to separate the text strings from the code.  >Perhaps we should generate a global help xml file to hold the text, or maybe a >help directory to hold multiple files, and then also have a game->specific help file for including any game-specific help information.

You need to read up on internationalization (aka I18N) and localization (aka L10N). Basically your code ends up referring to property names, which are then looked up in property files for the actual text. Different versions of the props file(s) are provided for each locale, and the user's settings determine which one is used.

ISTR the tutorial trail on Suns's Java website explaining the process covered it very nicely, and didn't take long to read. I internationalised a small app in about couple of hours, including reading the tutorial. There's also an Eclipse wizard which helps configure it all for you.

I'd advise having a small number of files, probably only one for the base 
application, rather than one per package (which is the alternative). Also make sure you use Format strings where appropriate so that you can cope with parameters (e.g. company name, currency refs, etc) being in different places in the text in different languages.

Iain.

RE: [Rails-devel] Help

[Brett L. <wak...@ea...>]

Yes, it's even in the Sun API:

http://java.sun.com/developer/technicalArticles/Intl/IntlIntro/


---Brett.


-----Original Message-----
From: "John A. Tamplin" <ja...@ja...>
Sent: Nov 29, 2005 8:12 PM
To: rai...@li...
Subject: RE: [Rails-devel] Help

On Tue, 29 Nov 2005, Brett Lentz wrote:

> I just had a chance to look at the help system a little more in-depth.
>
> At some point we're going to want to separate the text strings from the 
> code.  Perhaps we should generate a global help xml file to hold the 
> text, or maybe a help directory to hold multiple files, and then also 
> have a game-specific help file for including any game-specific help 
> information.

Is there a Java equivalent to GNU gettext?

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Help

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

On Tue, 29 Nov 2005, Brett Lentz wrote:

> I just had a chance to look at the help system a little more in-depth.
>
> At some point we're going to want to separate the text strings from the 
> code.  Perhaps we should generate a global help xml file to hold the 
> text, or maybe a help directory to hold multiple files, and then also 
> have a game-specific help file for including any game-specific help 
> information.

Is there a Java equivalent to GNU gettext?

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

RE: [Rails-devel] Help

[Brett L. <wak...@ea...>]

I just had a chance to look at the help system a little more in-depth.

At some point we're going to want to separate the text strings from the code.  Perhaps we should generate a global help xml file to hold the text, or maybe a help directory to hold multiple files, and then also have a game-specific help file for including any game-specific help information.

---Brett.



-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 21, 2005 4:27 PM
To: rai...@li...
Subject: RE: [Rails-devel] Help

> Try a JTextPane:  
> http://java.sun.com/docs/books/tutorial/uiswing/components/text.html

Good suggestion, thanks.

I had looked at it before, but was put off by the
talking about editor kits etc.
But it can also be used in a very easy way to display simple HTML.
I have actually used its somewhat simpler superclass JEditorPane.

Erik.




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Special tile lays

[Brett L. <wak...@ea...>]

Excellent.    Due to the holidays here in the U.S., I haven't had much time to work on finishing up tokens.

I'm hoping to have some time this next week to do that.

---Brett


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Nov 27, 2005 4:06 PM
To: rai...@li...
Subject: [Rails-devel] Special tile lays

I have completed (I hope) the special tile lays for 1830.

There is no checking yet that tiles have a route to a token,
so the only effect currently is, that a company that owns C&StL
may lay an extra tile on hex B20 once.

Testing this kind of feature is tedious, and I can't yet
guarantee it to be bug-free.

Erik.




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Special tile lays

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

I have completed (I hope) the special tile lays for 1830.

There is no checking yet that tiles have a route to a token,
so the only effect currently is, that a company that owns C&StL
may lay an extra tile on hex B20 once.

Testing this kind of feature is tedious, and I can't yet
guarantee it to be bug-free.

Erik.

RE: [Rails-devel] Help

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

> Try a JTextPane:  
> http://java.sun.com/docs/books/tutorial/uiswing/components/text.html

Good suggestion, thanks.

I had looked at it before, but was put off by the
talking about editor kits etc.
But it can also be used in a very easy way to display simple HTML.
I have actually used its somewhat simpler superclass JEditorPane.

Erik.

RE: [Rails-devel] TokenHolders

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

> Brett Lentz wrote:
> > Is there any type of Token that isn't directly related to a Company?
> 
> The only one I can think of are the alpine-mountain tokens in 
> 18EU (which mean
> that it will cost money to play the second tile in each of 
> those hexes, even
> though the tiles aren't any different than those in 
> non-mountain locations).

Yes, I thought about these tokens too, but I don't think
we need to represent these with separate objects here.
As other people have stressed, we should display the upgrade cost anyhow.

I would propose to implement such upgrade costs internally as an array
(index = upgrade level). XML config for such hexes could be like
cost="120" for the standard case,
cost="120,60" for 18EU,

Upgrade cost tokens also exist in 1849 Sicily, where the same
fixed cost must be paid for *every* upgrade.
We could represent that with cost="160,*" (also "40,*" and "80,*"),
but there is a complication that the cost is different for narrow gauge:
25% of that for normal gauge (this is the incentive to build such gauge at
all).
Perhaps we'll have to create a special for this case!

Erik.