Re: [Rails-devel] Tile Database API & route calculation

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

> >>The tile code draws the entire city structure as one, and 
> >>only needs the 
> >>center point and orientation of the city structure.  For hit 
> >>detection, 
> >>I suggest that simply saving the calculated position is better than 
> >>trying to store that in the XML data, espeially since zooming and 
> >>panning is going to change where it is drawn.
> >>    
> >>
> >Yes, but to drop tokens we need the slot center locations 
> rather than the
> >city location. 
> >  
> >
> Yes, but how does that change my suggestion to calculate them 
> based on 
> the drawing of the tile rather than to store them in the XML and then 
> have to back-calculate the center point of the city structure for 
> drawing the tile? 

I agree with your suggestion, which I had not noticed before.
(A few posts ago I asked whether you intended to calculate 
slot spots bases on city drawing, and I didn't notice a clear
answer to that. Apologies if I missed it.)
I never intended to suggest back-calculation.
 
> >That will work in many cases, but by far not all 
> >(for instance the Y hexes in 18Scan, to name just one example).
> >The subject of having/not having default upgrade rules has been
> >discussed in 18xx-softdev a few years ago, and the conclusion then
> >was, that it would be best to specify all upgrades explicitly.
> >At that time I was the main dissenter, but I have converted 
> myself since.
> >Hence: the TileSet.xml files now specify all allowed upgrades.
> >I would prefer to keep it that way.
> >  
> >
> If you don't want to use the data, that is fine, but I really think 
> there should be one authoritive database (replicated of 
> course) for all 
> the tiles in the 18xx world.  Otherwise, we wind up with 
> problems like 
> the way things are today, where different games reuse tile numbers or 
> draw the same tiles differently.  As such, since my tile database and 
> John Galt's and others all have the category data, I think it 
> should be 
> included.  Ideally, I would like to be able to generate the XML for a 
> given game from an authoritive tile database.  Also ideally, the XML 
> version of the tile database would be useful for multiple software 
> packages (moderators, tile generation programs, PBeM map generators, 
> etc) to avoid further duplication.

I was not talking about the tiles database (now Tiles.xml), 
but about the amount of tiles per game and the location 
of the preprinted tiles on the map, all of which are now in
TileSet.xml, together with the upgrade rules and any per-hex
tile laying restictions.

I made that distinction on purpose: Tiles.xml is generic
(although there is now a subset per game, but that subset is 
not essential indeed, only a speed-up),
and TileSet.xml has anything that is game-specific regarding the
usage of the tiles.
I hope you don't intend to mix up that distinction.

(BTW, I generate the per-game Tiles.xml from the generic Tiles.xml
and the per-game TileSet.xml, this is done by the stand-alone
class util.MakeGameTileSets.
No manual work except running this class!).

> I find it useful to have default behavior even if it doesn't 
> cover all 
> cases -- in the exceptions, you can override the default 
> behavior as needed.

In general I agree, but in this case the saving of code by 
not having to sort out all the default upgrades and then apply
any exceptions IMO far outweighs the extra effort to specify all
upgrades beforehand. I'm not going to write *that* code!
In other words, feel free to add categories but I won't use these.

However, a stand-alone program to fill up a skeleton TileSet.xml with 
the default upgrade rules, which then can be edited manually
would be very nice as a contribution from your side!
Or perhaps a program to expand a TileSet with inclusion
and exclusion upgrade rules to one that fully specifies all allowed 
upgrades. But I can live without any of these.

Erik.