rails-devel

[Rails-devel] 18EU Tile number overlaps

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

I'm working on importing the new tiles for 18EU, but I've run into some
overlaps in tile numbering.

I was able to import the TileDesigner data from John. Unfortunately,
these tiles already exist (and are different tiles): -5, -6, -7, -8, -9,
-10, -11, 80, 81, 82, 83.

So, it looks like I'll need to re-number these 18EU tiles. Any
suggestions on what the new tile numbers ought to be?


 ---Brett.


	"Fantasies are free."
	"NO!! NO!! It's the thought police!!!!"

Re: [Rails-devel] 18EU Tile number overlaps

[Chris S. <chr...@gm...>]

I strongly suggest you keep the same numbers, but indicate in some way
that they are variants.  The game should be as similar to the printed
version as possible, despite tile numbering conflicts.

Chris


On 10/24/07, Brett Lentz <wak...@gm...> wrote:
> I'm working on importing the new tiles for 18EU, but I've run into some
> overlaps in tile numbering.
>
> I was able to import the TileDesigner data from John. Unfortunately,
> these tiles already exist (and are different tiles): -5, -6, -7, -8, -9,
> -10, -11, 80, 81, 82, 83.
>
> So, it looks like I'll need to re-number these 18EU tiles. Any
> suggestions on what the new tile numbers ought to be?
>
>
>  ---Brett.
>
>
>         "Fantasies are free."
>         "NO!! NO!! It's the thought police!!!!"
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>


-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

Chris Shaffer wrote:
> I strongly suggest you keep the same numbers, but indicate in some way
> that they are variants.  The game should be as similar to the printed
> version as possible, despite tile numbering conflicts.
>   
You already have to deal with multiple identical tile numbers that have 
different track.  I suggest using the same solution I do in my database 
-- I have a unique tile ID and an attribute of the tile is the number to 
display on the tile.

Also, note that tiles 80-83 are in fact identical to the "standard" 
80-83 -- they have the same connectivity between edges, but are just 
drawn differently.

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

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, John A. Tamplin <ja...@ja...> wrote:
> Chris Shaffer wrote:
> > I strongly suggest you keep the same numbers, but indicate in some way
> > that they are variants.  The game should be as similar to the printed
> > version as possible, despite tile numbering conflicts.
> >
> You already have to deal with multiple identical tile numbers that have
> different track.  I suggest using the same solution I do in my database
> -- I have a unique tile ID and an attribute of the tile is the number to
> display on the tile.
>
> Also, note that tiles 80-83 are in fact identical to the "standard"
> 80-83 -- they have the same connectivity between edges, but are just
> drawn differently.
>


Just to play devil's advocate for a moment...

What's the reasoning behind keeping the tile numbering the same?  If
it's merely because that's what people already know and use for PBEM,
that reasoning strikes me as tenuous at best.  So long as Rails uses
an internally consistent numbering scheme, the tile numbering is
largely irrelevant for actual gameplay.

In other words, the gameplay value of Tile #9 isn't the fact that it's
number nine, but the fact that it represents track going from one side
of the hex to the opposite side in a straight line. So, therefore
whether it's labelled 9 or 99 doesn't really matter at all, does it?

FWIW - I believe the previous numbering collisions were dealt with by
bumping the tile numbers into a new range (e.g. 65 became 2065).
Though, my memory isn't clear on this point, which is what instigated
the question in the first place. :-)


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

[Chris S. <chr...@gm...>]

On 10/24/07, brett lentz <wak...@gm...> wrote:
>
> What's the reasoning behind keeping the tile numbering the same?  If
> it's merely because that's what people already know and use for PBEM,
> that reasoning strikes me as tenuous at best.  So long as Rails uses
> an internally consistent numbering scheme, the tile numbering is
> largely irrelevant for actual gameplay.
>
> In other words, the gameplay value of Tile #9 isn't the fact that it's
> number nine, but the fact that it represents track going from one side
> of the hex to the opposite side in a straight line. So, therefore
> whether it's labelled 9 or 99 doesn't really matter at all, does it?

Yes, it does matter, because people often rely on printed tile upgrade
charts and lists.  Also, upgrade possibilities are often delineated in
the rules by tile number.  Since you can't update those documents, you
should be consistent with them.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

Chris Shaffer wrote:
> Yes, it does matter, because people often rely on printed tile upgrade
> charts and lists.  Also, upgrade possibilities are often delineated in
> the rules by tile number.  Since you can't update those documents, you
> should be consistent with them.
>   
I am saying that 18EU's tile #80 is identical in function to the 
"standard" tile #80 -- I view the graphic differences as no different 
than whether a bridge symbol is drawn on overpasses or what font the 
revenue number is drawn in.

I'm not suggesting using different tile numbers -- I am saying to 
distinguish game X's tile A from game Y's tile A each tile would have a 
unique tile id, which is not printed on the tile, while the tile number 
attribute would be A in each case.

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

Re: [Rails-devel] 18EU Tile number overlaps

[Chris S. <chr...@gm...>]

> I am saying that 18EU's tile #80 is identical in function to the
> "standard" tile #80 -- I view the graphic differences as no different
> than whether a bridge symbol is drawn on overpasses or what font the
> revenue number is drawn in.

Agreed - I think the cases that matter are the ones where there are
real conflicts.

> I'm not suggesting using different tile numbers -- I am saying to
> distinguish game X's tile A from game Y's tile A each tile would have a
> unique tile id, which is not printed on the tile, while the tile number
> attribute would be A in each case.

Definitely agree on this - the display should match the documentation
and printed game.  A unique ID that isn't displayed will do fine, as
you suggested earlier.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, Chris Shaffer <chr...@gm...> wrote:
> > I'm not suggesting using different tile numbers -- I am saying to
> > distinguish game X's tile A from game Y's tile A each tile would have a
> > unique tile id, which is not printed on the tile, while the tile number
> > attribute would be A in each case.
>
> Definitely agree on this - the display should match the documentation
> and printed game.  A unique ID that isn't displayed will do fine, as
> you suggested earlier.
>

That was really the crux of the original question.  The tile number
printed on the image itself remains unchanged.  Unfortunately, modern
filesystems don't allow me to have two versions of "tile80.svg", so I
need to pick one of the overlapping images and call it something else.


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

[Chris S. <chr...@gm...>]

> Hmm...  either I don't understand your description, or I have a
> completely different design goal, but that sounds way more complex
> than it really needs to be to implement a playable game.  Having
> multiple tiles that are the same ID but different rotations doesn't
> make sense to me. Why wouldn't you have one tile, know the starting
> rotation, then calculate the other rotations?

Because the orientation/location of the printed number on the tile is
what is used by players in play-by-email to describe the position of
the tile.  You have to account for all the possibilities in playing
the game.

I'm currently in a play-by-email game with someone who can charitably
be described as computer-illiterate.  Over the course of the game,
we've had to reset his turn and rebuild the spreadsheet several times.
 If we didn't have a consistent way to describe tile orientations
(within that particular game, compared to the actual physical copy of
the game that he owns and has set up in his basement), we wouldn't be
able to play.  Despite the challenges of playing with this fellow, I'm
really enjoying the game, and he's a good player.  He just has no clue
how the computer really works.

Thus, it's important to mimic the printed games as closely as
possible, as John Tamplin described.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

brett lentz wrote:
> That was really the crux of the original question.  The tile number
> printed on the image itself remains unchanged.  Unfortunately, modern
> filesystems don't allow me to have two versions of "tile80.svg", so I
> need to pick one of the overlapping images and call it something else.
>   
Then use the unique ID in the filename -- it can be anything you like.  
Note that the code field in the TileDesigner data is insufficient as 
there are still duplicates across different games and there are 
different orientations for the same tile number (sometimes even within 
the same game!).  My solution to the latter problem is to have a tile 
id, rotation, and count in the tile manifest table for a game, so there 
can be multiple rotations of the same tile in one game.

A related problem is that some games have had different tile mixes over 
the years, such as some 1825/1829 sets (and maybe 1853).  My solution 
for those is to treat them as different games which happen to have the 
same name.

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

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
> > That was really the crux of the original question.  The tile number
> > printed on the image itself remains unchanged.  Unfortunately, modern
> > filesystems don't allow me to have two versions of "tile80.svg", so I
> > need to pick one of the overlapping images and call it something else.
> >
> Then use the unique ID in the filename -- it can be anything you like.
> Note that the code field in the TileDesigner data is insufficient as
> there are still duplicates across different games and there are
> different orientations for the same tile number (sometimes even within
> the same game!).  My solution to the latter problem is to have a tile
> id, rotation, and count in the tile manifest table for a game, so there
> can be multiple rotations of the same tile in one game.
>

Hmm...  either I don't understand your description, or I have a
completely different design goal, but that sounds way more complex
than it really needs to be to implement a playable game.  Having
multiple tiles that are the same ID but different rotations doesn't
make sense to me. Why wouldn't you have one tile, know the starting
rotation, then calculate the other rotations?

> A related problem is that some games have had different tile mixes over
> the years, such as some 1825/1829 sets (and maybe 1853).  My solution
> for those is to treat them as different games which happen to have the
> same name.

My plan is similar to how we've handled variants like 1830's optional
6 train: construct the game engine API to allow the UI to manipulate
these values prior to game startup.


---Brett

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, Chris Shaffer <chr...@gm...> wrote:
> > Hmm...  either I don't understand your description, or I have a
> > completely different design goal, but that sounds way more complex
> > than it really needs to be to implement a playable game.  Having
> > multiple tiles that are the same ID but different rotations doesn't
> > make sense to me. Why wouldn't you have one tile, know the starting
> > rotation, then calculate the other rotations?
>
> Because the orientation/location of the printed number on the tile is
> what is used by players in play-by-email to describe the position of
> the tile.  You have to account for all the possibilities in playing
> the game.
>
> I'm currently in a play-by-email game with someone who can charitably
> be described as computer-illiterate.  Over the course of the game,
> we've had to reset his turn and rebuild the spreadsheet several times.
>  If we didn't have a consistent way to describe tile orientations
> (within that particular game, compared to the actual physical copy of
> the game that he owns and has set up in his basement), we wouldn't be
> able to play.  Despite the challenges of playing with this fellow, I'm
> really enjoying the game, and he's a good player.  He just has no clue
> how the computer really works.
>
> Thus, it's important to mimic the printed games as closely as
> possible, as John Tamplin described.
>


Hmm...  I think there's the exact disconnect.

You see, with an implementation like Rails, that eliminates the causes
for much of those problems.   Rather than trying to figure out what
version of the printed game each player has, you all centralize on the
same computer version, which handles all of those details for you.
This allows you to just focus on the printed image rather than trying
to get verbal descriptions correct.


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

[Chris S. <chr...@gm...>]

> Hmm...  I think there's the exact disconnect.
>
> You see, with an implementation like Rails, that eliminates the causes
> for much of those problems.   Rather than trying to figure out what
> version of the printed game each player has, you all centralize on the
> same computer version, which handles all of those details for you.
> This allows you to just focus on the printed image rather than trying
> to get verbal descriptions correct.

Yup, that's the disconnect.  You'd think people would centralize on
the computer version, but that's definitely not always going to be the
case, and it assumes a lot about people's behavior.  In my experience,
we use Cyberboard and Vassal gameboxes in many ways that are
unanticipated by the module/program designers.

One scenario: there have been a number of times that we've played a
partial game at the game store, which closes at 10pm.  We then write
down as much as we can, take a couple of snapshots of the board, and
close up for the night.  Later, I convert all of that to Cyberboard
and a spreadsheet.  We play some of the game by email, some of us
using Cyberboard, some of us simply relying on the notes, photos and
an occasional screenshot sent by the others.  Then, a while later, one
of us sets up the game at the game shop and we finish it out.

Another scenario: we're all using Vassal to play 18AL via direct
connect.  Partway through the game, we wrap it up and convert to play
by email.  One guy can't run programs at work, but still takes turns,
relying on printouts and his physical copy of the rules and charts -
including the tile upgrade charts.  If he had to wait until he could
run the program, it would slow down the pbem portion of the game quite
a bit.

That's a long way of saying you're not making new games, you're
converting old ones -- and imho, it's worth the time and effort to be
as consistent as possible with the printed copies of the games.
Introducing any variance is a way of introducing the possibility of
rules arguments - something to be avoided.

I don't see why this is a real issue, actually.  John pointed out the
easy solution.  Simply use an internal ID system.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/25/07, Chris Shaffer <chr...@gm...> wrote:
> > Hmm...  I think there's the exact disconnect.
> >
> > You see, with an implementation like Rails, that eliminates the causes
> > for much of those problems.   Rather than trying to figure out what
> > version of the printed game each player has, you all centralize on the
> > same computer version, which handles all of those details for you.
> > This allows you to just focus on the printed image rather than trying
> > to get verbal descriptions correct.
>
> Yup, that's the disconnect.  You'd think people would centralize on
> the computer version, but that's definitely not always going to be the
> case, and it assumes a lot about people's behavior.  In my experience,
> we use Cyberboard and Vassal gameboxes in many ways that are
> unanticipated by the module/program designers.
>
> One scenario: there have been a number of times that we've played a
> partial game at the game store, which closes at 10pm.  We then write
> down as much as we can, take a couple of snapshots of the board, and
> close up for the night.  Later, I convert all of that to Cyberboard
> and a spreadsheet.  We play some of the game by email, some of us
> using Cyberboard, some of us simply relying on the notes, photos and
> an occasional screenshot sent by the others.  Then, a while later, one
> of us sets up the game at the game shop and we finish it out.
>
> Another scenario: we're all using Vassal to play 18AL via direct
> connect.  Partway through the game, we wrap it up and convert to play
> by email.  One guy can't run programs at work, but still takes turns,
> relying on printouts and his physical copy of the rules and charts -
> including the tile upgrade charts.  If he had to wait until he could
> run the program, it would slow down the pbem portion of the game quite
> a bit.
>
> That's a long way of saying you're not making new games, you're
> converting old ones -- and imho, it's worth the time and effort to be
> as consistent as possible with the printed copies of the games.
> Introducing any variance is a way of introducing the possibility of
> rules arguments - something to be avoided.
>
> I don't see why this is a real issue, actually.  John pointed out the
> easy solution.  Simply use an internal ID system.
>


It's not a real issue. As I already said, we don't (and won't) change
the tile number printed on the tile graphic.

However, this information is helpful in preventing the exact thing you
described: developers not knowing how their software is being used and
not incorporating that information into their design goals.


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

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

On Thu, 25 Oct 2007, brett lentz wrote:

> It's not a real issue. As I already said, we don't (and won't) change
> the tile number printed on the tile graphic.
>
> However, this information is helpful in preventing the exact thing you
> described: developers not knowing how their software is being used and
> not incorporating that information into their design goals.

So, just to make sure I understand your position, are you saying it is or 
is not a design goal to be able to use Rails with physical copies of the 
games to play by mail/email?  That is really the entire point of the tile 
numbers themselves, so I would suggest that if you do not agree that 
should be a goal there is no point putting the tile numbers on there at 
all.

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

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/25/07, John A. Tamplin <ja...@ja...> wrote:
> On Thu, 25 Oct 2007, brett lentz wrote:
>
> > It's not a real issue. As I already said, we don't (and won't) change
> > the tile number printed on the tile graphic.
> >
> > However, this information is helpful in preventing the exact thing you
> > described: developers not knowing how their software is being used and
> > not incorporating that information into their design goals.
>
> So, just to make sure I understand your position, are you saying it is or
> is not a design goal to be able to use Rails with physical copies of the
> games to play by mail/email?  That is really the entire point of the tile
> numbers themselves, so I would suggest that if you do not agree that
> should be a goal there is no point putting the tile numbers on there at
> all.
>


It's not a primary concern. I'd call it a low priority design goal.
If we can do it easily without adding a lot of extra overhead, we'll
try to fit it in.

If there's someone who wants to dedicate some effort to working on the
tile images, then it will happen a lot faster.


---Brett

Re: [Rails-devel] 18EU Tile number overlaps

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

On Thu, 25 Oct 2007, brett lentz wrote:

> If there's someone who wants to dedicate some effort to working on the
> tile images, then it will happen a lot faster.

What exactly do you need?  I can generate EPS and PNG directly from the 
tile database for arbitrary games.  SVG would be a bit more work, but 
perhaps my tile data could be loaded into TileDesigner with less effort, 
and I believe it generates reasonable SVG.

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

Re: [Rails-devel] 18EU Tile number overlaps

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

On Thu, 2007-10-25 at 13:05 -0400, John A. Tamplin wrote:
> On Thu, 25 Oct 2007, brett lentz wrote:
> 
> > If there's someone who wants to dedicate some effort to working on the
> > tile images, then it will happen a lot faster.
> 
> What exactly do you need?  I can generate EPS and PNG directly from the 
> tile database for arbitrary games.  SVG would be a bit more work, but 
> perhaps my tile data could be loaded into TileDesigner with less effort, 
> and I believe it generates reasonable SVG.
> 

Unfortunately TileDesigner does not generate usable SVG. I'm not sure if
the problem is TileDesigner or the Batik library, but I've already gone
down that path.

The way I've been obtaining SVGs is to export to PS from TileDesigner,
then use pstoedit to convert them to SVG. From there, each tile needs a
bit of tweaking that I have been doing with Inkscape, but should be
scriptable without too much trouble.

So, ideally, what I need is GIFs and SVGs of each tile.  Or, if that
won't work for you, I'd also accept a more complete TileDesigner
database.


 ---Brett.


  Our comedies are not to be laughed at. -Samuel Goldwyn

Re: [Rails-devel] 18EU Tile number overlaps

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

18EU tiles 80-83 look different from those in older games, 
but aren't with respect to what connections exist.
And for route determination (in the future) we will need the edge-to-edge
connections, as specified in the XML tile spec of the 'classical' format
(i.e. the existing tiles 80-83).

A simple solution would be to keep using the existing tile pictures.
If you (understandably) would like to use the new 18EU format, 
one solution would be to give these pictures a high number 
(like 5080 etc), but otherwise use the existing low-numbered
specs.

The XML in 18EU/TileSet.xml for these tiles could then be like
	<Tile id="80" pic="5080" quantity="4">
		<Upgrade id="545,546" />
	</Tile>

The Tile spec in Tiles.xml should stay like
	<Tile colour="green" id="80" name="80">
		<Track from="side1" gauge="normal" to="side2"/>
		<Track from="side1" gauge="normal" to="side3"/>
		<Track from="side2" gauge="normal" to="side3"/>
	</Tile>
or similar. The new-style XML spec for 5080 would not be used.

Similar considerations apply to 544-546, although we don't have
a 'classical' format there. But we need at least an XML version
of it on behalf of Tiles.xml.

----------

On tiles -5 through -11: 
I think -10 and perhaps -11 already existed in Marco's
original TileDesigner, has John changed these? 
-5 through -9 are free as far as I am concerned.	

----------

On duplicate numbers for really different tiles: 
here indeed we should use internal and external numbers.

The current attribute "id" is intended to be unique internal number.
If the external number (shown in the UI etc.) is different,
we need an additional attribute for that purpose.

----------

On different "base" rotations: we'll need an extra attribute
in TileSet.xml for that purpose, for instance (just a random example):
	<Tile id="26" rotation="2" quantity="2">
		<Upgrade id="42,44,45" />
	</Tile>
All reported rotations (inclusing those in Map.xml) 
would be relative to this base rotation.

I agree with the posters who maintain that we should remain
consistent with the tiles as they exist in each game.
Even then we face problems: in 1830, tile #45 exists in two
different base rotations! How do PBEMmers solve that problem?


Erik.


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of Brett Lentz
> Sent: Thursday 25 October 2007 00:03
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 18EU Tile number overlaps
> 
> I'm working on importing the new tiles for 18EU, but I've run 
> into some
> overlaps in tile numbering.
> 
> I was able to import the TileDesigner data from John. Unfortunately,
> these tiles already exist (and are different tiles): -5, -6, 
> -7, -8, -9,
> -10, -11, 80, 81, 82, 83.
> 
> So, it looks like I'll need to re-number these 18EU tiles. Any
> suggestions on what the new tile numbers ought to be?
> 
> 
>  ---Brett.
> 
> 
> 	"Fantasies are free."
> 	"NO!! NO!! It's the thought police!!!!"
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and 
> a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] 18EU Tile number overlaps

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

Revisiting

> The Tile spec in Tiles.xml should stay like
> 	<Tile colour="green" id="80" name="80">
> 		<Track from="side1" gauge="normal" to="side2"/>
> 		<Track from="side1" gauge="normal" to="side3"/>
> 		<Track from="side2" gauge="normal" to="side3"/>
> 	</Tile>
> or similar. The new-style XML spec for 5080 would not be used.

and
 
> On duplicate numbers for really different tiles: 
> here indeed we should use internal and external numbers.
> 
> The current attribute "id" is intended to be unique internal number.
> If the external number (shown in the UI etc.) is different,
> we need an additional attribute for that purpose.

I can add, that in fact we already have the 'name' attribute 
containg the external numbers 
(except for preprinted tiles numbered < 0, but those don't matter).

See for instance in the generic tiles/Tiles.xml:

	<Tile colour="green" id="12" name="12">
		<Station id="city1" position="0" slots="1" type="City"
value="30"/>
		<Track from="city1" gauge="normal" to="side1"/>
		<Track from="city1" gauge="normal" to="side2"/>
		<Track from="city1" gauge="normal" to="side3"/>
	</Tile>
	<Tile colour="green" id="1012" name="12">
		<Station id="city1" position="0" slots="2" type="City"
value="50"/>
		<Track from="city1" gauge="normal" to="side1"/>
		<Track from="city1" gauge="normal" to="side2"/>
		<Track from="city1" gauge="normal" to="side3"/>
	</Tile>

So we're fine on that aspect.

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

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

On Thu, 25 Oct 2007, Erik Vos wrote:

> 18EU tiles 80-83 look different from those in older games,
> but aren't with respect to what connections exist.
> And for route determination (in the future) we will need the edge-to-edge
> connections, as specified in the XML tile spec of the 'classical' format
> (i.e. the existing tiles 80-83).

Actually that doesn't matter, as you already have to be able to trace 
connectivity through junctions.

> A simple solution would be to keep using the existing tile pictures.
> If you (understandably) would like to use the new 18EU format,
> one solution would be to give these pictures a high number
> (like 5080 etc), but otherwise use the existing low-numbered
> specs.
>
> The XML in 18EU/TileSet.xml for these tiles could then be like
> 	<Tile id="80" pic="5080" quantity="4">
> 		<Upgrade id="545,546" />
> 	</Tile>
>
> The Tile spec in Tiles.xml should stay like
> 	<Tile colour="green" id="80" name="80">
> 		<Track from="side1" gauge="normal" to="side2"/>
> 		<Track from="side1" gauge="normal" to="side3"/>
> 		<Track from="side2" gauge="normal" to="side3"/>
> 	</Tile>
> or similar. The new-style XML spec for 5080 would not be used.
>
> Similar considerations apply to 544-546, although we don't have
> a 'classical' format there. But we need at least an XML version
> of it on behalf of Tiles.xml.

There the connectivity actually is different.

> On tiles -5 through -11:
> I think -10 and perhaps -11 already existed in Marco's
> original TileDesigner, has John changed these?
> -5 through -9 are free as far as I am concerned.

I corrected orientations on a number of them

> On duplicate numbers for really different tiles:
> here indeed we should use internal and external numbers.
>
> The current attribute "id" is intended to be unique internal number.
> If the external number (shown in the UI etc.) is different,
> we need an additional attribute for that purpose.

In the data I sent, code is the unique id and number is the value to 
displayed on the tile if different from code.

> On different "base" rotations: we'll need an extra attribute
> in TileSet.xml for that purpose, for instance (just a random example):
> 	<Tile id="26" rotation="2" quantity="2">
> 		<Upgrade id="42,44,45" />
> 	</Tile>
> All reported rotations (inclusing those in Map.xml)
> would be relative to this base rotation.

Yes, that is what I do (except the map rotation is relative to the tile 
manifest rotation).

> I agree with the posters who maintain that we should remain
> consistent with the tiles as they exist in each game.
> Even then we face problems: in 1830, tile #45 exists in two
> different base rotations! How do PBEMmers solve that problem?

I remember Steve Thomas had a solution for that, but I don't remember what 
it was.

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

Re: [Rails-devel] 18EU Tile number overlaps

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

> In the data I sent, code is the unique id and number is the value to 
> displayed on the tile if different from code.

I haven't seen yet what you have sent, John.
Was it a complete tile set for all games that you have covered,
or a subset for 18EU?

We should somehow agree on a common numbering and XML format.
The overall tiles/Tiles.xml has been created from Marco's TileDesigner file,
extended by me, by a conversion utility.

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

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

On Thu, 25 Oct 2007, Erik Vos wrote:

> I haven't seen yet what you have sent, John.
> Was it a complete tile set for all games that you have covered,
> or a subset for 18EU?

I posted it here a couple of weeks ago -- I think it was just the EU 
special tiles.

> We should somehow agree on a common numbering and XML format.
> The overall tiles/Tiles.xml has been created from Marco's TileDesigner file,
> extended by me, by a conversion utility.

I am not sure there are common interests.  I took the TileDesigner format 
and extended it for my needs, and then I have a database schema where the 
authoritive data is kept which also has a lot more detail about rendering. 
Initially the detailed layout data was automatically generated from 
code derived from TileDesigner, then I could manually tweak it if needed 
(and there is a flag saying if it was automatically generated so it can be 
regenerated if I improve the layout code).

Since Rails doesn't render the tiles from the tile data, it seems like 
most of that data is useless to Rails.  Also, I currently do not keep 
information useful for route calculations which Rails will eventually 
need, although I wouldn't be averse to extended it and storing it as well. 
Finally, I am more concerned with a unified database of all tiles so I can 
search for which games contain which tiles etc while Rails doesn't care 
for such a database (at least that is my recollection of a discussion 
about this a couple of years ago).

XML is not a particularly good format for storing the data, but it is good 
for information interchange.  I would be willing to write import/export 
code from my database to some common XML format if it seems useful.  I 
have extended TileDesigner data for every game I produce and most of the 
others (and I imported connectivity data from ps18xx tiles, but many of 
them have poor layout data).

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

Re: [Rails-devel] 18EU Tile number overlaps

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

> Since Rails doesn't render the tiles from the tile data, it 
> seems like 
> most of that data is useless to Rails.  Also, I currently do not keep 
> information useful for route calculations which Rails will eventually 
> need, although I wouldn't be averse to extended it and 
> storing it as well. 
> Finally, I am more concerned with a unified database of all 
> tiles so I can 
> search for which games contain which tiles etc while Rails 
> doesn't care 
> for such a database (at least that is my recollection of a discussion 
> about this a couple of years ago).

Our "database" is a big file named Tile.xml that has all the tiles 
that currently exist in our version of the TileDesigner file. 
I run the XML exported by TileDesigner through a utility that 
extracts the connectivity information from it*.

>From this big file, another utility extracts the tiles needed 
for a particular game into a game-specific subset Tiles.xml file.

As it is now, we have to live which the original TileDesigner
features. This does not cover all our graphics needs 
(for instance, we can't create off-board tiles with "arrows"), 
but for creating the connectivity XML in a simple way 
it seems good enough to me.

I'll look at your upload later.

For now it seems to me, that I can best continue to create new
tiles via TileDesigner for the purpose of XML creation,
whereas Brett can meanwhile work with you to see if we can obtain
better graphics that way.

Any remaining numbering or naming differences can be resolved via our 
manually coded TileSet.xml files, e.g. by the 'pic' attribute
that I proposed in an earlier post.

Erik.

*which is why I prefer the old-style 80-83 tiles for this purpose.

Re: [Rails-devel] 18EU Tile number overlaps

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

On Fri, 26 Oct 2007, Erik Vos wrote:

> Our "database" is a big file named Tile.xml that has all the tiles
> that currently exist in our version of the TileDesigner file.
> I run the XML exported by TileDesigner through a utility that
> extracts the connectivity information from it*.

What XML exported from TileDesigner are you referring to?  Is there a new 
version that supports XML?

> For now it seems to me, that I can best continue to create new
> tiles via TileDesigner for the purpose of XML creation,
> whereas Brett can meanwhile work with you to see if we can obtain
> better graphics that way.

I think you will find it easier to start with the TileDesigner data I 
provided (and can provide for most other games) and remove the extensions 
I added than to start from scratch, but however you want to do it is fine.

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