Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@xs...> - 2010-05-15 22:46:08
|
nd another question: Anyone suggest better colors (RGB values) for the routing paths. I do not know, if I have time to figure out, how I make those configurable from the properties file. [EV] I'm willing to look at that. [EV2] Now done. See the new my.properties file. |
|
From: Stefan F. (web.de) <ste...@we...> - 2010-05-16 21:01:09
|
Erik: thanks a lot. At least in my case I have to copy the color definitions to my properties file and uncomment the colors, otherwise I cannot start or load any game. Same is true for running from the supplied my.properties without uncommenting the error is raised: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at rails.ui.swing.MapPanel.<init>(MapPanel.java:40) Stefan On Sunday 16 May 2010 00:46:15 Erik Vos wrote: > nd another question: Anyone suggest better colors (RGB values) for the > routing paths. I do not know, if I have time to figure out, how I make > those > > configurable from the properties file. > > [EV] I'm willing to look at that. > > [EV2] Now done. See the new my.properties file. > > > --------------------------------------------------------------------------- >--- > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2010-05-16 21:06:38
|
Yes, I have just fixed that one too. Should work now. Erik. -----Original Message----- From: Stefan Frey (web.de) [mailto:ste...@we...] Sent: Sunday 16 May 2010 23:01 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] revenue library Erik: thanks a lot. At least in my case I have to copy the color definitions to my properties file and uncomment the colors, otherwise I cannot start or load any game. Same is true for running from the supplied my.properties without uncommenting the error is raised: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at rails.ui.swing.MapPanel.<init>(MapPanel.java:40) Stefan On Sunday 16 May 2010 00:46:15 Erik Vos wrote: > nd another question: Anyone suggest better colors (RGB values) for the > routing paths. I do not know, if I have time to figure out, how I make > those > > configurable from the properties file. > > [EV] I'm willing to look at that. > > [EV2] Now done. See the new my.properties file. > > > --------------------------------------------------------------------------- >--- > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel ---------------------------------------------------------------------------- -- _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2010-05-19 18:57:41
|
Stefan,
I have no major problem with your solution, but I doubt if it will prove to
be "sustainable" in the long term.
How would you address:
- 1825, where the restriction that only one city on a hex can be visited
applies to all OO-style hexes? There are quite some of these hexes on all
the units and regional kits, and the tiles are standard OO tiles.
- 1860, where a similar rule applies to *all* tiles, including such plain
track tiles as green 16-22, as well as some special tiles. Here the rule
simply is: if a train has left any hex, it may not reenter that same hex.
Here it is not a city/station property, not even a hex property but a game
property.
I'd go for some way to assign that last rule ("if a train has left any hex,
it may not reenter that same hex") to either selected hexes, or all hexes,
or (in cases where off-board areas span multiple hexes), sets of hexes. Such
an approach would cover all cases known to me.
Erik.
-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...]
Sent: Sunday 16 May 2010 23:49
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] revenue library
Erik:
see below.
On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> -> Berlin tile still has to be added to the hand-made tiles (city names to
> block double runs to yellow Berlin).
>
> [EV] Does this mean that the one and only function of Station city names
in
> the Tile definitions is to block multiple runs?
> That does not sound very logical to me. Cannot this blocking feature
(much)
> better be made a (single) MapHex property? Or, if it's colour-dependent,
in
> TileSet? Like <NoMultipleAccess/> or such?
I found it logical, but I came up with that solution, so that does not mean
too much. And all solutions have reasonable pro/cons. My reasons were:
A) Choosing the city attribute mirrors the solution for the offboard
locations/stations. The only difference is that for offboard locations the
city name (like the revenue value) is defined on the MapHex instead of
creating different tiles for each off-board area. Allows easy
implementation.
I only hope that no one ever comes up with two different off-map locations
combined on one hex, but that would cause headaches for the revenue value as
well.
B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to
split that information over various files.
C) Why not one property per MapHex/Tile? It allows easily to have
restrictions
that combine several hexes/tiles into one vertex set (as I call them). And
think about a tile with three stations, where only belong to one city.
I admit that all that is not required for the games currently implemented.
Stefan
----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. (web.de) <ste...@we...> - 2010-05-19 20:42:20
|
Erik:
yes you are right:
The city location vertex set rule does not cover cases below.
And you are right again that (any of) your suggested rule(s) would cover the
Berlin tile as well.
However there is some reason why I was reluctant to implement your rule:
The main issue is that is difficult to define the rule first and then to
transfer it to the vertex graph.
To cut that short:
1) Is the rule "only one city on a hex can be visited" (and does this mean
city or any kind of station?) or "if a train has left any hex,it may not
reenter that same hex".
2) Especially the implementation of the latter defintion is particularly hard
to convert into the vertex structure: If I define all side vertexes as a
vertex set, a train will never be able to leave the hex again. Most likely
this requires the addition of additional vertices for entry/departure of the
hex to control for that (where all of the entry vertices are defined as a
joint set).
Thus I will live with the simple definition for now and leave the more complex
cases for later.
Stefan
On Wednesday 19 May 2010 20:57:38 Erik Vos wrote:
> Stefan,
>
> I have no major problem with your solution, but I doubt if it will prove to
> be "sustainable" in the long term.
>
> How would you address:
>
> - 1825, where the restriction that only one city on a hex can be visited
> applies to all OO-style hexes? There are quite some of these hexes on all
> the units and regional kits, and the tiles are standard OO tiles.
>
> - 1860, where a similar rule applies to *all* tiles, including such plain
> track tiles as green 16-22, as well as some special tiles. Here the rule
> simply is: if a train has left any hex, it may not reenter that same hex.
> Here it is not a city/station property, not even a hex property but a game
> property.
>
> I'd go for some way to assign that last rule ("if a train has left any hex,
> it may not reenter that same hex") to either selected hexes, or all hexes,
> or (in cases where off-board areas span multiple hexes), sets of hexes.
> Such an approach would cover all cases known to me.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 16 May 2010 23:49
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] revenue library
>
> Erik:
> see below.
>
> On Saturday 15 May 2010 22:04:15 Erik Vos wrote:
> > -> Berlin tile still has to be added to the hand-made tiles (city names
> > to block double runs to yellow Berlin).
> >
> > [EV] Does this mean that the one and only function of Station city names
>
> in
>
> > the Tile definitions is to block multiple runs?
> > That does not sound very logical to me. Cannot this blocking feature
>
> (much)
>
> > better be made a (single) MapHex property? Or, if it's colour-dependent,
>
> in
>
> > TileSet? Like <NoMultipleAccess/> or such?
>
> I found it logical, but I came up with that solution, so that does not mean
> too much. And all solutions have reasonable pro/cons. My reasons were:
>
> A) Choosing the city attribute mirrors the solution for the offboard
> locations/stations. The only difference is that for offboard locations the
> city name (like the revenue value) is defined on the MapHex instead of
> creating different tiles for each off-board area. Allows easy
> implementation.
>
> I only hope that no one ever comes up with two different off-map locations
> combined on one hex, but that would cause headaches for the revenue value
> as
>
> well.
>
> B) Why not in TileSet? Stations are defined in Tile.xml, I did not want to
> split that information over various files.
>
> C) Why not one property per MapHex/Tile? It allows easily to have
> restrictions
> that combine several hexes/tiles into one vertex set (as I call them). And
> think about a tile with three stations, where only belong to one city.
> I admit that all that is not required for the games currently implemented.
>
> Stefan
>
> ---------------------------------------------------------------------------
>- --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: alexti <al...@sh...> - 2010-05-21 03:17:23
|
On Wed, 19 May 2010 14:42:10 -0600, Stefan Frey (web.de) <ste...@we...> wrote: > Erik: > yes you are right: > > The city location vertex set rule does not cover cases below. > And you are right again that (any of) your suggested rule(s) would cover > the > Berlin tile as well. > > However there is some reason why I was reluctant to implement your rule: > The main issue is that is difficult to define the rule first and then to > transfer it to the vertex graph. > > To cut that short: > 1) Is the rule "only one city on a hex can be visited" (and does this > mean > city or any kind of station?) or "if a train has left any hex,it may not > reenter that same hex". > > 2) Especially the implementation of the latter defintion is particularly > hard > to convert into the vertex structure: If I define all side vertexes as a > vertex set, a train will never be able to leave the hex again. Most > likely > this requires the addition of additional vertices for entry/departure of > the > hex to control for that (where all of the entry vertices are defined as a > joint set). > > Thus I will live with the simple definition for now and leave the more > complex > cases for later. If you're going to switch to the 2-phased approach, this situation will be easy to describe through segment exclusions - two segments terminating in different cities on the same hex are mutually exclusive for the same train. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X