Menu
▾
▴
rails-devel
|
From: Mark S. <mar...@gm...> - 2008-10-21 01:16:39
|
Grumble... I feel like I just took one step forward... and five steps back. I was able to get XCode to properly commit a change to CVS at Source Forge (I added a two lines to the AUTHORS file, a blank line and 'TEST'), I created a whole new XCode project, set up the repository fresh, with my Source Forge User name, did a code checkout to get the entire code base, and then modified the file. That seems to have fixed that issue. But now I am back with the original problem I had when I first checked the code out when I was trying to get the stupid thing to compile and run. It would compile (28 warmings due to 'deperacated' routines in Rails that were called elsewhere in Rails). But it won't find the main routine. I fixed it before by adjusting the Manifest file and creating a new routine 'Rails' with the main routine (rather than GameTest). But it is now being very stubborn. I still cannot commit with my original project, which makes me think there is something buried in there that is saving the original anonymous configuration when trying to do a checkin. I can tell from the XCode use I have been doing, that this will work very well, once it is all configured correctly. But it is very very fustrating. Mark |
|
From: Brett L. <wak...@gm...> - 2008-10-21 16:21:35
|
On Mon, 2008-10-20 at 20:16 -0500, Mark Smith wrote: > Grumble... I feel like I just took one step forward... and five steps > back. > > I was able to get XCode to properly commit a change to CVS at Source > Forge (I added a two lines to the AUTHORS file, a blank line and > 'TEST'), I created a whole new XCode project, set up the repository > fresh, with my Source Forge User name, did a code checkout to get the > entire code base, and then modified the file. That seems to have fixed > that issue. > > But now I am back with the original problem I had when I first checked > the code out when I was trying to get the stupid thing to compile and > run. It would compile (28 warmings due to 'deperacated' routines in > Rails that were called elsewhere in Rails). But it won't find the main > routine. I fixed it before by adjusting the Manifest file and creating > a new routine 'Rails' with the main routine (rather than GameTest). > But it is now being very stubborn. I still cannot commit with my > original project, which makes me think there is something buried in > there that is saving the original anonymous configuration when trying > to do a checkin. > > I can tell from the XCode use I have been doing, that this will work > very well, once it is all configured correctly. But it is very very > fustrating. > > Mark > I've not used XCode, so I'm not sure how it deals with things. With Eclipse, when I try to run a project it gives me the ability to point it at the class containing main(), and it runs from there. Does XCode not have a similar mechanism? FWIW, there is an OS X version of Eclipse. ;-) ---Brett. "Life, loathe it or ignore it, you can't like it." -- Marvin the paranoid android |
|
From: Mark S. <mar...@gm...> - 2008-10-21 23:48:00
|
There is the standard way of updating the Manifest.txt (or manifest.txt) file to specify the default class that has the main routine. I did that the first time I pulled down the code base via anonymous retrieval, and got it to compile, including finding a fixing a few other bugs. I just have to kick XCode hard enough to make it see reason. I do like XCode, and have developed most of my code base there. I do know there is a Mac version of Eclipse, but that would probably mean taking 20 steps back and getting used to a new IDE. My original intention was to update the SCM configuration for XCode to use the authorized account 'krazick', and I did so in every place I could find, but it still insisted on using the anonymous login instead. It made no sense. Which is why I tried creating a new project from scratch and the SCM configuration worked then. I will get it straightened out, it just is being annoying... which is why I was grumbling... Thanks for the words of encourgagement. |
|
From: Mark S. <mar...@gm...> - 2008-10-23 23:49:04
|
I think I have it finally straightened out... the hitch was when I first checked out the code, I was doing it anonymously, so the CVS created various CVS directories with a 'ROOT' File that contained the Repository String as anonymous. Later when I changed the Repository Setting, and applied it, XCode did not walk through the tree and update those various files. I did that change now on the copy I have gotten to compile and run, and I can now do write commits. Most annoying... But I am over that now... so I can actually look at the next step of fixing a few more bugs, and trying to work out integrating my code base with yours. I do have a different Tile Definition layout, and it would probably be best to determine how best to integrate them together. Mark On Tue, Oct 21, 2008 at 6:47 PM, Mark Smith <mar...@gm...> wrote: > There is the standard way of updating the Manifest.txt (or manifest.txt) > file to specify the default class that has the main routine. I did that the > first time I pulled down the code base via anonymous retrieval, and got it > to compile, including finding a fixing a few other bugs. I just have to kick > XCode hard enough to make it see reason. I do like XCode, and have developed > most of my code base there. > > I do know there is a Mac version of Eclipse, but that would probably mean > taking 20 steps back and getting used to a new IDE. > > My original intention was to update the SCM configuration for XCode to use > the authorized account 'krazick', and I did so in every place I could find, > but it still insisted on using the anonymous login instead. It made no > sense. Which is why I tried creating a new project from scratch and the SCM > configuration worked then. I will get it straightened out, it just is being > annoying... which is why I was grumbling... > > Thanks for the words of encourgagement. > > |
|
From: Brett L. <wak...@gm...> - 2008-10-24 00:01:53
|
On Thu, 2008-10-23 at 18:49 -0500, Mark Smith wrote: > I think I have it finally straightened out... the hitch was when I > first checked out the code, I was doing it anonymously, so the CVS > created various CVS directories with a 'ROOT' File that contained the > Repository String as anonymous. Later when I changed the Repository > Setting, and applied it, XCode did not walk through the tree and > update those various files. I did that change now on the copy I have > gotten to compile and run, and I can now do write commits. > > Most annoying... > > But I am over that now... so I can actually look at the next step of > fixing a few more bugs, and trying to work out integrating my code > base with yours. > Huzzah! > I do have a different Tile Definition layout, and it would probably be > best to determine how best to integrate them together. > Well, let's dig into it then. In my mind, the most important question is, how do you add new tiles? The current, rather convoluted, process is to create a new tile with Tile Designer, export the postscript file, convert it to SVG and GIF, then hand-tweak the SVG and GIF files. Obviously this is sub-optimal, but the tile set changes relatively infrequently, so I've just accepted the inefficiencies. If it's relatively easy to create new tiles in your format, I'm not opposed to ripping out the current tile sub-system entirely. > Mark > ---Brett. "Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai > On Tue, Oct 21, 2008 at 6:47 PM, Mark Smith <mar...@gm...> > wrote: > There is the standard way of updating the Manifest.txt (or > manifest.txt) file to specify the default class that has the > main routine. I did that the first time I pulled down the code > base via anonymous retrieval, and got it to compile, including > finding a fixing a few other bugs. I just have to kick XCode > hard enough to make it see reason. I do like XCode, and have > developed most of my code base there. > > I do know there is a Mac version of Eclipse, but that would > probably mean taking 20 steps back and getting used to a new > IDE. > > My original intention was to update the SCM configuration for > XCode to use the authorized account 'krazick', and I did so in > every place I could find, but it still insisted on using the > anonymous login instead. It made no sense. Which is why I > tried creating a new project from scratch and the SCM > configuration worked then. I will get it straightened out, it > just is being annoying... which is why I was grumbling... > > Thanks for the words of encourgagement. > |
|
From: Erik V. <eri...@hc...> - 2008-10-24 19:53:43
|
> > I do have a different Tile Definition layout, and it would
> probably be
> > best to determine how best to integrate them together.
One missing item in Map.xml is the hex name (like A1, B2 etc).
Hex names are indipensible in PBEM play, and anyway generally useful
in discussing games.
> Well, let's dig into it then. In my mind, the most important question
> is, how do you add new tiles?
>
> The current, rather convoluted, process is to create a new tile with
> Tile Designer, export the postscript file, convert it to SVG and GIF,
> then hand-tweak the SVG and GIF files. Obviously this is sub-optimal,
> but the tile set changes relatively infrequently, so I've
> just accepted
> the inefficiencies.
In addition, I export the XML definitions from TileDesigner and let class
rails.util.convertTilesXML convert these to the format used in Tiles.xml.
The converted format is meant to support future route checking and revenue
calculation (but nothing of that has happened yet).
> If it's relatively easy to create new tiles in your format, I'm not
> opposed to ripping out the current tile sub-system entirely.
Or merge the two. The differences are actually not that large.
> > Revenue Centers can be towns (whistlestops or
> > small city), or Large Cities (single, double, triple, quad).
One more minor quibble from my side:
You use the term "RevenueCenter" where we now have "Station".
("Junction" might be another option, although perhaps confusing
with respect to point tiles like #23-#31.)
My point is that there are junctions/stations/revenuecenters
that do not generate revenue, such as the 1841 passes and tunnels
(but these *do* count against the train length and can be tokened,
so they might as well be considered 0-revenue Cities). I admit
that Station might also be confusing as this term is also used for base
tokens.
In 1860 we also have halts, and in 1854 medium cities.
> I believe 18EU has new tiles. 18KAAS is just 1830 with a new map.
18Kaas also has new tiles (B+ = B with 2 token slotes, and U).
> > The 1835
> > Hamburg Tile with the tunnel is something I have not quite resolve how
> > to draw properly yet.
It's actually a ferry.
TileDesigner can't handle this one either. I doubt if any XML can define
this one in a generic way without becoming overly complicated. For token
placement and revenue calculation we might need to resort to special code
in an 1835-specific class. For drawing, I don't know...
Erik.
|
|
From: Mark S. <mar...@gm...> - 2008-10-24 00:21:22
|
> > Well, let's dig into it then. In my mind, the most important question > is, how do you add new tiles? > > The current, rather convoluted, process is to create a new tile with > Tile Designer, export the postscript file, convert it to SVG and GIF, > then hand-tweak the SVG and GIF files. Obviously this is sub-optimal, > but the tile set changes relatively infrequently, so I've just accepted > the inefficiencies. > > If it's relatively easy to create new tiles in your format, I'm not > opposed to ripping out the current tile sub-system entirely. > > > The current way I create Tiles is I create the tile definitions is by hand. I laid out various points around the tile (center of each edge, points in the hex that are near a side, near a corner, far from side, far from corner, etc... and the center. Each of the Features of the tiles live either at one of these points, or extending across two points (like track segments). A Feature is like a Port, a Revenue Center (City or Town), a Terrain Feature, etc. Privates are a two-point feature to draw the "track" segment for them. Revenue values are a feature, Names are a Feature... Basically just about anything that needs to be drawn on the hex/tile is a feature. One exception is the Blocked Hexsides, which is a feature of each hex (max 6) that is drawn AFTER any tile is drawn so that it overlaps the drawn tile. The hexes that allow only a Green Tile to be placed initially, is drawn as either a solid yellow hex (like 1835) or a Thick Yellow Frame (like 1830/1856). Revenue Centers can be towns (whistlestops or small city), or Large Cities (single, double, triple, quad). The 1835 Hamburg Tile with the tunnel is something I have not quite resolve how to draw properly yet. But I do have as part of my existing tile definition base is every tile that 1830, 1835, 1853, 1856 and 1870 use. I would also need to look at 18EU, 18KAAS, and such to see if they have any new ones. Each Game has a Tile Set specifies the collections of tiles used the game from the common Tile Definition Sets. You should be able look athe XML FIles in the Data directory of my code base and see something about what I am talking about. Mark |
|
From: Brett L. <wak...@gm...> - 2008-10-24 00:52:12
|
On Thu, 2008-10-23 at 19:21 -0500, Mark Smith wrote: > > > > Well, let's dig into it then. In my mind, the most important > question > is, how do you add new tiles? > > The current, rather convoluted, process is to create a new > tile with > Tile Designer, export the postscript file, convert it to SVG > and GIF, > then hand-tweak the SVG and GIF files. Obviously this is > sub-optimal, > but the tile set changes relatively infrequently, so I've just > accepted > the inefficiencies. > > If it's relatively easy to create new tiles in your format, > I'm not > opposed to ripping out the current tile sub-system entirely. > > > > > The current way I create Tiles is I create the tile definitions is by > hand. I laid out various points around the tile (center of each edge, > points in the hex that are near a side, near a corner, far from side, > far from corner, etc... and the center. Each of the Features of the > tiles live either at one of these points, or extending across two > points (like track segments). A Feature is like a Port, a Revenue > Center (City or Town), a Terrain Feature, etc. Privates are a > two-point feature to draw the "track" segment for them. Revenue > values are a feature, Names are a Feature... Basically just about > anything that needs to be drawn on the hex/tile is a feature. One > exception is the Blocked Hexsides, which is a feature of each hex (max > 6) that is drawn AFTER any tile is drawn so that it overlaps the drawn > tile. The hexes that allow only a Green Tile to be placed initially, > is drawn as either a solid yellow hex (like 1835) or a Thick Yellow > Frame (like 1830/1856). Revenue Centers can be towns (whistlestops or > small city), or Large Cities (single, double, triple, quad). The 1835 > Hamburg Tile with the tunnel is something I have not quite resolve how > to draw properly yet. > > But I do have as part of my existing tile definition base is every > tile that 1830, 1835, 1853, 1856 and 1870 use. I would also need to > look at 18EU, 18KAAS, and such to see if they have any new ones. > I believe 18EU has new tiles. 18KAAS is just 1830 with a new map. > Each Game has a Tile Set specifies the collections of tiles used the > game from the common Tile Definition Sets. > > You should be able look athe XML FIles in the Data directory of my > code base and see something about what I am talking about. > > Mark Interesting. I'd skimmed the XML files when you sent me the game engine, but they're difficult to decipher without the rest of the source code to know how you're processing them. ;-) I can't immediately see any major problems with your method of defining and drawing hexes. However, it obviously needs documentation (and maybe even a DTD) to help anyone else create new tiles. Is the 1835 Hamburg tile the only tile you've had difficulty defining? ---Brett. Van Roy's Law: Honesty is the best policy - there's less competition. Van Roy's Truism: Life is a whole series of circumstances beyond your control. |
|
From: Brett L. <wak...@gm...> - 2008-10-24 20:32:32
|
On Fri, 2008-10-24 at 21:53 +0200, Erik Vos wrote:
> > > I do have a different Tile Definition layout, and it would
> > probably be
> > > best to determine how best to integrate them together.
>
> One missing item in Map.xml is the hex name (like A1, B2 etc).
> Hex names are indipensible in PBEM play, and anyway generally useful
> in discussing games.
>
> > Well, let's dig into it then. In my mind, the most important question
> > is, how do you add new tiles?
> >
> > The current, rather convoluted, process is to create a new tile with
> > Tile Designer, export the postscript file, convert it to SVG and GIF,
> > then hand-tweak the SVG and GIF files. Obviously this is sub-optimal,
> > but the tile set changes relatively infrequently, so I've
> > just accepted
> > the inefficiencies.
>
> In addition, I export the XML definitions from TileDesigner and let class
> rails.util.convertTilesXML convert these to the format used in Tiles.xml.
> The converted format is meant to support future route checking and revenue
> calculation (but nothing of that has happened yet).
>
> > If it's relatively easy to create new tiles in your format, I'm not
> > opposed to ripping out the current tile sub-system entirely.
>
> Or merge the two. The differences are actually not that large.
>
> > > Revenue Centers can be towns (whistlestops or
> > > small city), or Large Cities (single, double, triple, quad).
>
> One more minor quibble from my side:
> You use the term "RevenueCenter" where we now have "Station".
> ("Junction" might be another option, although perhaps confusing
> with respect to point tiles like #23-#31.)
> My point is that there are junctions/stations/revenuecenters
> that do not generate revenue, such as the 1841 passes and tunnels
> (but these *do* count against the train length and can be tokened,
> so they might as well be considered 0-revenue Cities). I admit
> that Station might also be confusing as this term is also used for base
> tokens.
>
> In 1860 we also have halts, and in 1854 medium cities.
>
Naming conventions aside, I think there are (at least) two conceptual
directions to choose from:
A) There's a single object, call it a "location", that has various
potential attributes such as "revenue" and "counts as a stop". When we
need a new feature, we'd just add another attribute or find a clever use
for our existing attributes (e.g. revenue="0").
B) We have a hierarchy of objects. Starting with a basic "location" that
has a minimum set of basic attributes, and building up specific
sub-classes of objects for specific purposes and use-cases.
I personally don't know enough of the 18xx differences to know which
approach would be more maintainable over the long-term. I'll let you
guys weigh in on that. ;-)
> > I believe 18EU has new tiles. 18KAAS is just 1830 with a new map.
>
> 18Kaas also has new tiles (B+ = B with 2 token slotes, and U).
>
> > > The 1835
> > > Hamburg Tile with the tunnel is something I have not quite resolve how
> > > to draw properly yet.
>
> It's actually a ferry.
> TileDesigner can't handle this one either. I doubt if any XML can define
> this one in a generic way without becoming overly complicated. For token
> placement and revenue calculation we might need to resort to special code
> in an 1835-specific class. For drawing, I don't know...
>
I don't know the rules around this tile. Can one of you give a
description of the game mechanics around this tile?
> Erik.
---Brett.
There's something different about us -- different from people of Europe,
Africa, Asia ... a deep and abiding belief in the Easter Bunny.
-- G. Gordon Liddy
|
|
From: Erik V. <eri...@hc...> - 2008-10-24 22:29:21
|
> Naming conventions aside, I think there are (at least) two conceptual > directions to choose from: > > A) There's a single object, call it a "location", that has various > potential attributes such as "revenue" and "counts as a stop". When we > need a new feature, we'd just add another attribute or find a > clever use > for our existing attributes (e.g. revenue="0"). Be warned that "counts as a stop" may be different for different train types, which is why I have thought to define it as a train rather than a tile property so far. For instance, in 1841 the passes count as stops for all trains except the largest (8) train. In the current Game.xml files I have used "majorStops" and "minorStops" per train, but actually we should be able to refine that further, to describe what type(s) of location count as major/minor stops. (The difference major/minor refers to the 2+2 etc. trains like we have in e.g. 1835. This is NOT the city/town difference except when it matters for such n+m trains). For instance, in 1830 we might add an attribute major="City,Town,OffBoard" to all trains (or to one general tag). In 1841 we might have major="City,Pass,Tunnel,OffBoard" and minor="Town,Port" (here the minor stations never count as stops) except for 8-trains, which would be different. Then we havs 18Scan and 1826 and others, which have E-trains that skip all towns (no stop, no revenue). > B) We have a hierarchy of objects. Starting with a basic > "location" that > has a minimum set of basic attributes, and building up specific > sub-classes of objects for specific purposes and use-cases. > I personally don't know enough of the 18xx differences to know which > approach would be more maintainable over the long-term. I'll let you > guys weigh in on that. ;-) A) and B) don't exclude each other. I think we should give each type of location/station a type attribute in the XML that gives it a sufficiently descriptive name, as I have tried to do it so far. Whether or not we need separate location (station) subclasses in the Java code is unclear (we'll find out when implementing routes and revenue), but I think not. I own quite a number of games, and from the start I have tried to give some thought to all variations I'm aware of, and to try making things as generic as possible, but with the infinite creativity of our game designers it is impossible to foresee all variations.... > > > I believe 18EU has new tiles. 18KAAS is just 1830 with a new map. > > > > 18Kaas also has new tiles (B+ = B with 2 token slotes, and U). > > > > > > The 1835 > > > > Hamburg Tile with the tunnel is something I have not > quite resolve how > > > > to draw properly yet. > > > > It's actually a ferry. > > TileDesigner can't handle this one either. I doubt if any > XML can define > > this one in a generic way without becoming overly > complicated. For token > > placement and revenue calculation we might need to resort > to special code > > in an 1835-specific class. For drawing, I don't know... > > > > I don't know the rules around this tile. Can one of you give a > description of the game mechanics around this tile? The green Hamburg (HH) tile has two single-slot cities east of the river Elbe and one west of it. In the brown tile, these cities are merged into one 3-slot city, but the slots and the tokens in it remain located as before: 2 east and one west of the Elbe. If a train passes the river on its route, even when only starting from or terminating at the token of its company, revenue is reduced by 10 Mark, being the cost of using the ferry. Much fuss for a little difference, but so the designer has decided it. Erik. |
|
From: Brett L. <wak...@gm...> - 2008-10-24 22:53:19
|
On Sat, 2008-10-25 at 00:29 +0200, Erik Vos wrote: > > > > > The 1835 > > > > > Hamburg Tile with the tunnel is something I have not > > quite resolve how > > > > > to draw properly yet. > > > > > > It's actually a ferry. > > > TileDesigner can't handle this one either. I doubt if any > > XML can define > > > this one in a generic way without becoming overly > > complicated. For token > > > placement and revenue calculation we might need to resort > > to special code > > > in an 1835-specific class. For drawing, I don't know... > > > > > > > I don't know the rules around this tile. Can one of you give a > > description of the game mechanics around this tile? > > The green Hamburg (HH) tile has two single-slot cities > east of the river Elbe and one west of it. > In the brown tile, these cities are merged into one 3-slot city, > but the slots and the tokens in it remain located as before: > 2 east and one west of the Elbe. > > If a train passes the river on its route, even when only starting from > or terminating at the token of its company, revenue is reduced by 10 Mark, > being the cost of using the ferry. > > Much fuss for a little difference, but so the designer has decided it. > Ok. I see why it might be difficult with the existing markups. It seems like this just means that the XML, and the code needs to be aware of where the cities are positioned in relationship to the hex sides. That would allow us to calculate "If the entering side is X, and the city is Y, revenue is Z-10". This sounds like it would just be a game-specific exception. It's a pain to not have a more general solution. However, if it's the only game that does this, a more general solution isn't necessary. > Erik. ---Brett. After the game the king and the pawn go in the same box. -- Italian proverb |
|
From: John A. T. <ja...@ja...> - 2008-10-24 23:39:20
|
On Fri, 24 Oct 2008, Brett Lentz wrote:
>> If a train passes the river on its route, even when only starting from
>> or terminating at the token of its company, revenue is reduced by 10 Mark,
>> being the cost of using the ferry.
>>
>> Much fuss for a little difference, but so the designer has decided it.
>>
>
> Ok. I see why it might be difficult with the existing markups. It seems
> like this just means that the XML, and the code needs to be aware of
> where the cities are positioned in relationship to the hex sides. That
> would allow us to calculate "If the entering side is X, and the city is
> Y, revenue is Z-10".
>
> This sounds like it would just be a game-specific exception. It's a
> pain to not have a more general solution. However, if it's the only game
> that does this, a more general solution isn't necessary.
1854 also has something similar, where passing through a particular
section of track results in a -10 reduction in revenue.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Chris S. <chr...@gm...> - 2008-10-24 23:51:45
|
> 1854 also has something similar, where passing through a particular > section of track results in a -10 reduction in revenue. And 1844 has tunnels, which add +10 to all stations on the route. -- Chris Please consider the environment before printing this e-mail. |
|
From: Mark S. <mar...@gm...> - 2008-10-25 00:04:41
|
I do seem to have gotten your attention. :-) Lengthy response here: So to answer your various questions: 1. Yes, I should produce some documentation, and a DTD on how to define tiles that are used in my code base. I have written notes, and penciled diagrams that I can use to re-produce this. 2. The 1835 Hamburg Grey Tile with the "Ferry" or "Tunnel", or whatever you want to call it is the one that is critical since the track for the ferry is drawn on top of the tri-city background, rather than on the base grey tile color. I am not sure why it would make a real difference in game implementation. 3. There are a few other tiles that the 18xx.net Tile Encylopedia has that gives me a little trouble, but some of the Tiles I don't currently draw, but should not be difficult to implement: a. S01, S02, S03, S04, etc which has a red # in a grey box, I have no idea what this represents. b. Tiles Straight Ferry Tiles (Red-Dashed Track) c. 1825 Tiles with mixed background color (brown & green, and brown & grey d. Mountain Pass tiles with track as shown at http://18xx.net/tiles/f9.htm, where the Track and the city are outlined d. Tunnel Entrances e. Tiles with the small town grey tick with a label of "l" Lira Symbol 4. Other problem tiles, are the double-hex tiles in 18MEX for Mexico City. 5. I use the term Revenue Center specifically, because it is an object that produces revenue. A Junction is simply a connection point between two or more track segments. I don't see a Junction object as having any real value. Or put another way, I double a Junction object would have any code at all associated with it, and no data either. It is purely an abstract concept. The code base is designed so that when I get to the point of selecting a track route, you go from point-to-point. If a point has a Revenue Center, you add that to you run (or not, if the train type and game allows you to ignore it). The selection code would not allow you to select a track segment already used by another train in the same operational step. 6. I do have a object hierarchy that has worked fairly well, and I need to get that out to you for review. It is a bit detailed, and I have revised it over the years. The basic idea is, that if it needs to be drawn on the hex, it gets a location. 7. The other issue I forsee is the "overlay" tiles for the True Tunnels. This would require allowing two (or maybe more) tiles to be associated with an individual hex. Maybe for the few games that allow this, a special extended class of MapCell that allows two tiles to be played on the same tile is possible... but only for the mapcells that allow a tunnel. 8. Given that I put the Tile Definitions in a set of generic files, that is not game specific, but I have for each game a Tile Set that says which tiles to use, in which quantity, once the tile is defined, it doesn't have to be copied to each game. It can be re-used. 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch my current product, and then let you mouse hover over a hex, a tool tip shows you the cell name. It is not defined in the XML files, other than the rowStart and colStart values on the first line of the Map.xml files. Every map cell name is deduced from that and the order the cells are shown in the file. It may be counting down, or counting up. But it does work on five maps I have coded up so far. Now, if some games (like 1851 with Cincinatti) have some awkward nameing sequences that may require a change, or at least an option to include them with the map cells definitions. 10. Passes in 1841 would most likely be an extension of a Large City with Zero Revenue to allow for token placement, and counting against. And maybe any other special code needed for Passes. (like drawing the outline around station and track). 11. I do track Red-Off Board cells as having a special type of location "dead-end" where the code would allow you to stop (or start) a train at, but not pass through. And it makes drawing the dead-end properly easier. Some games allows pass through (1856 Goderich hex), and it appears 1854 allows either a pass-through or something to Paris in West, and a city in the east (not sure the name) to add another station. Mark P.S. I will work on writing up a couple of pages that define my Tile Definition structure for posting. |
|
From: Chris S. <chr...@gm...> - 2008-10-25 01:23:34
|
> 5. I use the term Revenue Center specifically, because it is an object that > produces revenue. A Junction is simply a connection point between two or > more track segments. I don't see a Junction object as having any real value. > Or put another way, I double a Junction object would have any code at all > associated with it, and no data either. It is purely an abstract concept. Some games allow re-use of the tiny bit of track at the center of a plain track X tile, others do not. Thus, in some cases, a junction is an important concept. > The code base is designed so that when I get to the point of selecting a > track route, you go from point-to-point. If a point has a Revenue Center, > you add that to you run (or not, if the train type and game allows you to > ignore it). The selection code would not allow you to select a track segment > already used by another train in the same operational step. Note that the TGV in 1826 can re-use track. > 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch my > current product, and then let you mouse hover over a hex, a tool tip shows > you the cell name. Note that it is very important that this matches the notation used on the printed version of the game. I think you might have said you were accounting for that, but wanted to be sure it's included. > 11. I do track Red-Off Board cells as having a special type of location > "dead-end" where the code would allow you to stop (or start) a train at, but > not pass through. They also need to be counted as a location that some trains can't visit - in 1844, H trains cannot go to off-board hexes; in 18Scan, you can only go to an off-board hex if you have a token in it, etc. -- Chris Please consider the environment before printing this e-mail. |
|
From: Mark S. <mar...@gm...> - 2008-10-25 12:14:31
|
Chris, All good points. Given your example games, I will at this point have to plead ignorance. Each of those games came out after I had stopped playing 18xx steadily 10 years ago. Implementing a Junction to allow re-use and preventing re-use would not be a big issue with my code base. My Tile drawing techniques was implemented with the thought of each train a company owns would use independent track, and could be shown in different colors. Probably the TGV train would be a configuration item that would override the track-reuse testing, and draw it not as a colored track, but as maybe a dashed pattern. Or drawn alongside the track... have to think about it more. For the maps I have so far loaded up (1830, 1835, 1853, 1856, 1870) they all do match the printed boards. I have copies of each. I also have 1829 (North and South), and 1837 which I have not coded up yet. But I should work on 18EU and the other maps that Rails currently supports to be sure they work properly also. I am not saying my code will handle all possible variations, but until I come across something that does it differently, I will stand by my claim. (Or it can be fixed) For the 1844 H Trains, that is yet another train that would have a configuration option "No Dead End Track Segments allowed". For 18Scan that requires an off-board token yet another configuration option "Off Board Token Require for Off Board Use" Thanks for the input and new items I had not had privy too. Mark |
|
From: Chris S. <chr...@gm...> - 2008-10-25 12:40:38
|
> For the 1844 H Trains, that is yet another train that would have a > configuration option "No Dead End Track Segments allowed". Yup - it's a bit more complicated though - they are allowed to visit several types of dead end track segments (e.g. mountains and pre-printed grey hexes) but not *red* dead end track segments. -- Chris Please consider the environment before printing this e-mail. |
|
From: Mark S. <mar...@gm...> - 2008-10-25 13:17:40
|
OK... the option could certainly be "No Dead End Track Segments on RED Tiles... " With regards to your Junction example, of some games allow re-use, and some don't. Which ones don't allow a junction re-use? and What tile numbers (at least one example) so I can tell how it is drawn/represented. Given it is on Blackwater Station site. On Sat, Oct 25, 2008 at 7:40 AM, Chris Shaffer <chr...@gm...>wrote: > > For the 1844 H Trains, that is yet another train that would have a > > configuration option "No Dead End Track Segments allowed". > > Yup - it's a bit more complicated though - they are allowed to visit > several types of dead end track segments (e.g. mountains and > pre-printed grey hexes) but not *red* dead end track segments. > > -- > Chris > > Please consider the environment before printing this e-mail. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Chris S. <chr...@gm...> - 2008-10-25 13:35:12
|
> With regards to your Junction example, of some games allow re-use, and some > don't. Which ones don't allow a junction re-use? and What tile numbers (at > least one example) so I can tell how it is drawn/represented. Given it is on > Blackwater Station site. Tiles 544, 545, 546 are examples. http://www.18xx.net/tiles/e544.htm The 18Scan rules address such tiles with the following rule: "The junction in the middle of a green or brown plain track tile is not considered part of any track segment." 18EU says "Trains may not use track used by any of the Corporation's or Minor Company's other trains in the same Operating Round, except for junctions." Thus, in 18Scan and 18EU, two trains could run through tile 544. However, now that I go looking, I can't find specific examples of the contrary case. I remember there being a contrary example, but perhaps my memory is faulty. -- Chris Please consider the environment before printing this e-mail. |
|
From: Erik V. <eri...@hc...> - 2008-11-02 18:52:24
|
Allow me late reaction to a subject discussed a while ago: 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch my current product, and then let you mouse hover over a hex, a tool tip shows you the cell name. It is not defined in the XML files, other than the rowStart and colStart values on the first line of the Map.xml files. Every map cell name is deduced from that and the order the cells are shown in the file. It may be counting down, or counting up. But it does work on five maps I have coded up so far. Now, if some games (like 1851 with Cincinatti) have some awkward nameing sequences that may require a change, or at least an option to include them with the map cells definitions. The point is, that hex names are used a lot in configuring games, for instance to indicate hexes where certain private special properties can be exercised. Your way, that would require to first build and display the map with all preprinted tiles before the actual hex names can be found by hovering the mouse (or by looking at the printed board, hoping that the two will match). I would still prefer to find the hex names in Map.xml. A side note is, that I don't very much like and would personally prefer to leave out those nonfunctional water and land "hexes" (which aren't). Not sure what others think about this. My hope is, that someday, someone will build real maps, that can be used as a background on top of which the real (preprinted and laid) tiles are displayed. But perhaps that hope is idle... Erik. |
|
From: John D. G. <jd...@di...> - 2008-11-02 19:07:21
|
Mark Smith wrote: > 9. Erik mentioned the need for a hex name "A1, B2, etc". If you launch > my current product, and then let you mouse hover over a hex, a tool tip > shows you the cell name. It is not defined in the XML files, other than > the rowStart and colStart values on the first line of the Map.xml files. > Every map cell name is deduced from that and the order the cells are > shown in the file. It may be counting down, or counting up. But it does > work on five maps I have coded up so far. Now, if some games (like 1851 > with Cincinatti) have some awkward nameing sequences that may require a > change, or at least an option to include them with the map cells > definitions. 1853 is another game with an odd naming sequence for map hexes (capital letters one way, lower case the other, uses "i" but then skips "ai"...) Note: Do not rely on .gifs from David Reed's "The Depot" as a source for map hex names in general. Many of its maps get them wrong. |
|
From: Mark S. <mar...@gm...> - 2008-11-02 19:28:15
|
I could certainly include the hex names on the Map.xml file itself without any real difficulty. It just seemed an extra level of complexity. I do specify at the start of my map.xml files to specify the rowStart Value, and the Col Start Value. It all derives from those. But if it makes you happier to see them associated with the individual map cells, sure. And as for identifying the exact map cells that the Privates would be affecting, yes indeed that is a valid point. But it isn't like you can build this once and just know it will be right. There are always adjustments. And once you get it set correctly, you leave it alone. With regards to 1853, yes, the Rows have upper case letters, and the columns have lower case double letters. And I do account for that in my code. I have double-checked against my own copy of the game. With regards to using "The Depot" Site as a map cell name reference, I have not used that before. Each of the maps I have encoded are based upon copies I actually own. Erik's comment about the "non-functional land and water hexes"... Some games, like 1853 distinguish a difference between un-useable land hexes... some allow a railhead to connect to it, some do not. And regardless of that, the Water hexes are partly there to make the map appear "nicer", by more closely mimicing the actual printed board, but also it makes the verification of legal tile lays easier ... "You cannot dead-end into a hex side that is all water." Besides, if it really bugs you that much, internal Lakes (like in 1856) can be set as a Lake Type, and be drawn with a blue color, and Ocean hexes can be set as the default background color so they are drawn, but they won't change the background. And the goal is to have it configurable as a default setting (for all games), and a level for a specific game, and at a level for the individual player prefered. It would be solely based upon how your color scheme files would be set up. Personally I do like seeing the Ocean/Great Lake drawn as a Water Hex. As for finding someone down the road that will generate a "pretty background" that matches the original board exactly, and be scaleable... well that is not on my plate right now. Mark |
|
From: Chris S. <chr...@gm...> - 2008-11-02 19:52:42
|
Some games (I'm thinking of 18Scan, but I'm pretty sure there are others) define playable areas in terms of hexes, and do not have hexes in the water. If you print hexes where none exist in the published game, there might be confusion about rules references. Chris On Sun, Nov 2, 2008 at 11:28 AM, Mark Smith <mar...@gm...> wrote: > I could certainly include the hex names on the Map.xml file itself without > any real difficulty. It just seemed an extra level of complexity. I do > specify at the start of my map.xml files to specify the rowStart Value, and > the Col Start Value. It all derives from those. But if it makes you happier > to see them associated with the individual map cells, sure. And as for > identifying the exact map cells that the Privates would be affecting, yes > indeed that is a valid point. But it isn't like you can build this once and > just know it will be right. There are always adjustments. And once you get > it set correctly, you leave it alone. > > With regards to 1853, yes, the Rows have upper case letters, and the columns > have lower case double letters. And I do account for that in my code. I have > double-checked against my own copy of the game. > > With regards to using "The Depot" Site as a map cell name reference, I have > not used that before. Each of the maps I have encoded are based upon copies > I actually own. > > Erik's comment about the "non-functional land and water hexes"... Some > games, like 1853 distinguish a difference between un-useable land hexes... > some allow a railhead to connect to it, some do not. And regardless of that, > the Water hexes are partly there to make the map appear "nicer", by more > closely mimicing the actual printed board, but also it makes the > verification of legal tile lays easier ... "You cannot dead-end into a hex > side that is all water." Besides, if it really bugs you that much, internal > Lakes (like in 1856) can be set as a Lake Type, and be drawn with a blue > color, and Ocean hexes can be set as the default background color so they > are drawn, but they won't change the background. And the goal is to have it > configurable as a default setting (for all games), and a level for a > specific game, and at a level for the individual player prefered. It would > be solely based upon how your color scheme files would be set up. > > Personally I do like seeing the Ocean/Great Lake drawn as a Water Hex. > > As for finding someone down the road that will generate a "pretty > background" that matches the original board exactly, and be scaleable... > well that is not on my plate right now. > > Mark > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > -- Chris Please consider the environment before printing this e-mail. |
|
From: John D. G. <jd...@di...> - 2008-11-03 04:10:53
|
Mark Smith wrote: > With regards to 1853, yes, the Rows have upper case letters, and the > columns have lower case double letters. And I do account for that in my > code. I have double-checked against my own copy of the game. > > With regards to using "The Depot" Site as a map cell name reference, I > have not used that before. Each of the maps I have encoded are based > upon copies I actually own. Sorry, I didn't mean to step on your toes, I've just run into these conflicts in PBEM play. > Erik's comment about the "non-functional land and water hexes"... Some > games, like 1853 distinguish a difference between un-useable land > hexes... some allow a railhead to connect to it, some do not. And > regardless of that, the Water hexes are partly there to make the map > appear "nicer", by more closely mimicing the actual printed board, but > also it makes the verification of legal tile lays easier ... "You cannot > dead-end into a hex side that is all water." Besides, if it really bugs > you that much, internal Lakes (like in 1856) can be set as a Lake Type, > and be drawn with a blue color, and Ocean hexes can be set as the > default background color so they are drawn, but they won't change the > background. And the goal is to have it configurable as a default setting > (for all games), and a level for a specific game, and at a level for > the individual player prefered. It would be solely based upon how your > color scheme files would be set up. I'm not sure anyone has noticed since I haven't received any comments on it, but the "map" link from http://www.18xx.net/1853.htm now points to my own version of the map, with all eight company territories shown by cross-hatching. It's a bit messy, but it makes them more visible than other versions I've seen, and I've shown all the build costs too. |
|
From: Mark S. <mar...@gm...> - 2008-11-03 12:03:58
|
No toes were hurt by the message. I was just confirming the validity of your statement about not trusting an actual printed copy of the game. I have seen some site, even www.18xx.net have some errors in it (like the Tile Set for 1853). If you Look at: http://18xx.net/tiles/1853.htm And See Tile # 94 and # 95, as shown are the same tile. However, if you look at the actual copy of the game, each of these tiles should have only 4 track segments (2 Normal, 2 Metre) in a K formation, like Tile 96 and 97. And Yes, the 1853 Map you have is a bit on the "messy" side...:-) No offense. Mark |
×
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