From: Martin B. <dr....@t-...> - 2016-11-08 18:27:49
|
Tile identifiers Since Francis Tresham created the first 18xx game - it was 1829 - the tiles have a number printed on the face side to identify them. To make a long story short, the numbering of tiles in the growing 18xx genre was not a linear affair. We can read and see the fruits of efforts by individuals in the Tile Encyclopedia <https://web-beta.archive.org/web/20130111061408/http://www.18xx.net/tiles/index.htm>. The consequences for the Rails projects are mainly: * There are no identifiers for hexes on the maps * Some identifiers have been used for different tiles * Some identifiers have alphabetic characters, but TileDesigner 1.3.1 accepts only numbers The approach to circumvent these limitations is, since the "Storm and Stress"-phase till today, not standardized in Rails. Mainly it was up to the volunteers to come to a solution day by day. Erik Vos wrote a nice summary that can be found on Excerpts#Excerpt_002 <https://web-beta.archive.org/web/20130111061408/http://sourceforge.net:80/apps/mediawiki/rails/index.php?title=Excerpts#Excerpt_002> Working with TileDesigner /This section describes the setup and actions that are used by Erik Vos on his local Windows PC in creating tile images and XML. Not all of the mentioned files and scripts have been stored in the repository./ Introduction Most 18xx tiles for Rails are created with TileDesigner, a program written by Marco Rocci (see http://www.rails18xx.it/software.html <https://web-beta.archive.org/web/20130111061408/http://www.rails18xx.it/software.html> ). This program has not been maintained for many years, and we don't have the source code. But this program is currently all we have to create tiles, and the quality of the images is very good, so we have chosen to live with its limitations and bugs. TileDesigner is used to create both the tile images, and the XML files that describe each tile for the purpose of route and revenue calculation. Only the SVG image format is currently supported by Rails. It is possible to create SVG tile images in other ways (e.g. by editing existing SVG files in a text editor, or by Inkscape), but any new tile IDs created this way cannot be used as primary tile identifiers in the descriptive XML. See below for more details. Directory structure /Not prescriptive, but for information only/ My local directory structure, to which I will refer below, is shown here. Only files relevant to the tile creation process are mentioned. Only directories and files shown in *bold* are in the repository. *tiles* | +----------------------+-------------+-----------------+----------------+ | | | | | | *svg* TDwithID TDwoID handmade TileDesigner.exe | | | | *TileDictionary.18t* | +------+ +------+ | *TileDictionary.xml* | | | | | | *Tiles.xml* *tile#.svg* tile#.svg | tile#.svg | tile#.svg *CombineTiles.pl* | | *FixInvisibility.pl* TileDictionary TileDictionary tileset.bat | | tilexml.bat tile#.svg tile#.svg Designing tiles TileDesigner is not very well documented; a few hints on Marco Rocci's site is all we have. In its first run, the program uses the Italian language. For those who don't master that language: English can be selected under Modifica | Opzioni (Edit | Options), select Inglese (English). The user interface will not be described here. It has some quirks, but it is not too difficult to sort that out. /(If necessary, details can be added here in a later stage.)/ The order of tile numbers in the database (named *TileDesigner.18t*) is not sequential. The database contains Marco's original tile set followed by all tiles created for Rails in chronological sequence. To create a new tile, select the final tile id and press Ins. Then go ahead drawing junctions and tracks. It is essential that all track end points are either on a tile edge or on a junction (city, town), otherwise route calculation will fail. Exporting images To export SVG image files: Select File | Export | Images. Select or enter the following details: * Folder: where you want to store the images. Note: TD creates a subdirectory named *TileDictionary* /below/ the directory that is entered here and saves all image files in that subdirectory. * Image format: SVG * Scale: 1 * Tile size: 170 * Tile elements: o ID: either checked or unchecked, see below. o Grid: unchecked o Frame: checked * File name template: tile<c0> (note: this is essential, and deviates from the factory setting). * Leave all other options unchecked, except the Top checkboxes. Finally press OK. *Preprinted* tiles are exported to directory TDwoID. Uncheck the ID checkbox to ensure that the tile IDs are suppressed. *Layable* tiles are exported to directory TDwithID. Check the ID checkbox to ensure that the tile IDs are included. Export overwrites existing images in the TileDictionay subdirectories without warning. Fixing images For unknown reasons, TileDesigner includes 'xmlns=""', which makes the tiles invisible (note: this was not originally the case; I don't know what triggered it). To fix this, run the Perl script *FixInvisibility.pl* with the path to the relevant TileDictionary directory as a command-line argument. E.g. perl FixInvisibility.pl TDwithID/TileDictionary This script removes the xmlns attribute. A free Windows Perl implementation can be downloaded from http://www.activestate.com/activeperl <https://web-beta.archive.org/web/20130111061408/http://www.activestate.com/activeperl>. 'Handmade' images Many special tiles cannot be created by TileDesigner, which pretty much is limited to creating the kind of tiles known shortly after 2000. Other tiles can be created in various ways: * By editing an SVG file in a text editor (SVG is based upon XML). * By creating a new tile, or editing an existing tile in Inkscape (the leading SVG editor). In this case, special instructions apply (see below). Any tiles created or modified this way should be stored separately, to avoid being overwritten by a new export from TileDesigner. I am storing such tiles in the directory *handmade*. Instructions for Inkscape If tiles are modified with Inkscape, before saving, set the following properties before saving the new image: * Under File | DocumentProperties: o First press 'Fit page to selection'. For edited images, this should change the size to Width=393.00 and Height=341.00. o For unknown reasons, TileDesigner adds extra whitespace below the tile image. To emulate this, change the Height to 357.50. * Then save the tile. For newly created tiles, make sure that the size ends up identically, i.e. Width=393.00 and Height=357.00 /Note: I remember having had problems with using tiles newly created by Inkspace. That is why modifying existing tiles is recommended./ Publishing images To be included in the repository, the tile images must be copied to the *svg* directory. Usually I only copy new or changed tiles, first from *TileDictionary* to *TDwithID*/*TDwoID* (the contents of the latter serve as a backup up to that point). Then the relevant tiles from *TDwithID* (positive numbers), *TDwoID* (negative numbers and zero) and *handmade* are copied to *svg*. A Perl script named *CombineTiles.pl* exists that can do this job, but using it is not recommeded, as it overwrites all images in *svg*, which can cause excessive updates to the repository. These days, I'm only (manually) copying new or changed tiles. Creating XML tile descriptions Exporting XML from TileDesigner The file *TileDictionary.xml* contains all tile definitions in a TD-specific XML format. To export this file: * Select File | Export | XML. * Press OK. For this export action, it does not matter what options are selected or entered; everything is ignored. In particular, the contents of the *Folder* field is entirely ignored. TileDesigner always exports XML to the directory where the executable TileDesigner.exe is located. For this reason, it is recommended to store the executable in the Tiles directory. TileDictionary.xml is created as a one-line XML file. To properly format it, use the Perl script <tools_path>/formatxml.pl, or load the file in Eclipse and format it with XMLBuddy. Making Tiles.xml As explained elsewhere in this Wiki, Rails uses two types of files named *Tiles.xml*. The processes to create these files are explained below. *Warning*: never modify Tiles.xml files manually; such modifications will mercilessly be overwritten when the processes described below are executed. All additional tile properties must find a place in either TileSet.xml or Map.xml, as best fits the needs. The overall Tiles.xml file The overall *Tiles.xml* file is located in the *tiles* directory. It is created by running Java class *tools.ConvertTilesXML*, which is included in the Rails repository. I use the following Windows script (named *tilexml.bat*): java -Dconfigfile=<properties_path>.properties -cp <classes_path>\classes;<lib_path>\log4j-1.2.14.jar tools.ConvertTilesXML perl <tools_path>\formatxml.pl <tiles_path>\Tiles.xml pause where the properties file includes the log4j configuration (I suppose this is not really necessary). The Java program creates a one-line XML file. The Perl script formatxml.pl should properly format it. Alternatively, load it in Eclipse and format it with XMLBuddy. The per-game Tiles.xml file Each game has its own subset of tile descriptions in a file that is also named *Tiles.xml*, but is located in *data/<game-name>*. This type of file is created by running Java class *tools.MakeGameTileSets*, and uses the information in *TileSet.xml* (which must already exist) to create the per-game Tile.xml. The game name(s) must be provided as argument(s). I use the following Windows script, named *tileset.bat*: java -cp <classes_path>\classes;<lib_path>\log4j-1.2.14.jar tools.MakeGameTileSets %1 %2 %3 %4 %5 %6 %7 %8 %9 for %%A in (%*) do ( perl <tools_path>\formatxml.pl <data_path>\%%A\Tiles.xml ) pause Again, the Java program creates one-line XML files. The Perl script formatxml.pl should properly format each file. Alternatively, load each Tiles.xml file in Eclipse and format it with XMLBuddy. |