The first thing you need to know is that currently the HPS games have the MAP files locked out so that only the original MAP files will work within the game engine. You can make your own MAP file and load it into the Scenario Editor, it will work fine there and you can create a scenario file with it. However when you attempt to start the scenario file in the game engine you will get an error message. I have provided this section for those who are still using Corinth ver 1.01, which allowed you to load your own MAP files. The files were not locked until ver 1.02 and all game engines since then have been locked. Unfortunately this means you must play without all the engine updates that have been put into place since the Corinth 1.02 patch, something I'm not willing to do but I decided to provide this information for those of you who want it. It is also provided in the hopes that when the series has run it's course the game engines will be modified so that the MAP files are no longer locked.
The map file is actually a text file divided into several sections. Each of these sections contains the data need to determine different parts of the map. Once again I wish to thank the creators of the Cobexlaw site for permission to borrow from their site along with J.Pumphrey, Al Amos, G.Gorsuch who were given credit for much of the information on maps at the COBEXLAW site. Much of the information here is derived from their sites although some of it had to be changed due to differences between the ACW and Napoleonic era game engines.
|3.||Block 1: Terrain Types|
|4.||Block 2: Elevations|
|5.||Blocks 3-14: Hexside Features|
|6.||Block 15: Place Names|
|7.||Calculating the Checksum|
The HPS® map file "*.map" is a set of instructions to the main program on how to build the map in its working memory. The "*.map" files are located in the main folder of the game. The various bitmap files are located in the /map folder of the game. The map file contains a short 3-line header followed by up to 15 blocks of text. The first block gives terrain type, the second elevation, the next 12 hexside features, and the last place-names. Maps are very similar between games.
The header is the first three lines of text.
The first line contains just one character; so far, this is a "1" in all games.
The second line contains two numbers separated by a space. The first is the number of columns, and the second the number of rows. Thus in the Farmington map from Corinth, where the bottom right hex is (50,87) numbered 50,87 from 0,0 the values in the second line are "51 88".
The third line contains four numbers separated by spaces.
The first number is the base elevation, or height above sea level in metres of the starting elevation (value 0 in the elevation block, which will be dealt with below). In Farmington, this is 360 so the lowest elevation level is 360m above sea level.
The second number is the height in metres of each level of elevation. In the Farmington map it is 30m. The program multiplies this by the value in the elevation block and adds it to the base elevation to get the result which it displays.
The third number is the direction of North, coded counter-clockwise as follows:
The fourth number is a checksum value, which is calculated by totalling certain of the values in the map file. See below for a detailed account of calculating the checksum.
The fifth number is a 0 or a 1 in all cases so far. I currently have no idea what is the reason for that number's presence. If you know its use, please contact me about it.
This block consists of a character for each hex representing terrain type, or more precisely features which affect the hex as such, and not the hex sides. Where a clear hex is present, the character used is a space and the checksum number is 0. You can see this by selecting all the text in the block. In Farmington, you will see that a matrix of 51x88 characters is filled, even though most of them are spaces and thus invisible. This matrix must be maintained at all times if editing manually.
The character codes for the terrain types, and their checksum values, are as follows:
This block is always fully filled with values representing levels of elevation with 0 as the lowest level relative to the map. After the numbers 0-9, values continue with lower case letters of the alphabet, currently I have seen them as far as q giving 27 differrent elevation levels. Note that the values in the elevations block do not affect the checksum.
The next 10 blocks give hexside information broken down by type. All other data, apart from that dealt with above and placenames, is hexside data.
Each of these blocks 3-12 is headed, on a line of its own, by either a "0" or a "1". If by a "0", then no data follows and this hexside feature is not used on this map; if by a "1", then data follows and the full matrix must be filled as in the terrain and elevation blocks.
This data is in the form of a series of characters representing North-West, North, etc, hexsides and any combination of them. Here also spaces represent hexes with no marked sides.
Thus roads as well as fences or walls are treated purely as hexsides by the program. A road starting in the middle of a hex and passing through the South-East hexside has exactly the same character code and checksum value as a fence along the South-East hexside. Note that a road passing from the North-West to the South-East would have the same code as two fences, one to the North-West, and one to the South-East. Note further that a wall requires to be defined also in the adjoining hex, as do most similar types such as streams.
These various character codes which have a purely directional meaning by themselves, gain their terrain meaning
from which ever block they appear in, as follows:
This data is laid out in a table with an understandable pattern. One starts with North, then North-East, then combines the two; the 4th value is South-East, to which one then adds the pattern of the first 3, and so on.
The checksum values follow this pattern starting at 1. This progression gives, for the six points of the hex
"compass", the following checksum values:
A checksum value for any given combination of hexsides can be calculated by adding together these base values.
Each combination in the table is assigned a text character, starting with various special characters and passing through the numbers 1-9 and all (capital) letters of the alphabet. Programmers will recognize it as the ASCII sequence starting at hex (-adecimal... let's not get confused!) 21, and ending at 5F.
Here follows a complete list of these, showing the character used, the hexsides, and the checksum value. (The sequence I use is always clockwise from North -- No;NE;SE;So;SW;NW -- so a browser search can be used to find a particular combination):
(I have checked these values for this version and they are correct.)
The place names block has one name entry per line of text. The line consists of five numeric values and the name itself. The five values are column, row, font size, justification and color.
The values here have decimal places, and these indicate the precise starting (or ending--depending on justification) position of the text within the hex.
These are apparently 1-4. If you place a 0 for the Font size the location name is shown on the map in font size 1 but does not appear in the Locations window.
This, together with the decimal column/row positioning, allows for very exact placing of names and for proper placing on the far right of the map.
In addition to positioning the text itself using a 0 or a 2 places a + sign to the left or right of the text giving the exact position of the location itself on the map. When a 2 is used the location is the center of the text.
Color values are:
The exception to this is a building such as a house or church. In order to display a building in 2D or 3D the color number must between 3-8. The text color will always be black (color 0). Changing the color number will vary the building icon used for the hex in both 2D and 3D mode. The building displayed is determined by the color number -3. This sets the position of the building in the 2DFeatures and 3DFeatures files numbered from the left 0-5. This allows you to determine which building icon will be displayed in any particular hex although you are limited to the 6 choices in the file.
So in the Farmington file, the line
22.491 64.3438 2 1 0 Farmington
means text "Farmington" occurs in the center of hex (22,64), with font size 2, justified left, and in black.
Likewise the line
21.8727 66.0938 0 2 7 Farmington Church
means text "Farmington Church" occurs in the center of hex (21,66), with font size 1 (the 0 will prevent it from showing up in the Locations pull down window and display it in font size 1), justified left, in black and will result in building icon #4 (7-3) being displayed in the hex.
Theoretically a completely blank map file has a checksum value of zero. A map file with one column and one row, with a clear terrain type (space), has a checksum of 3. Thereafter each addition of 1 space to the row (ie. adding a new column) adds 2 to the total, but only for the first row; just 1 is added for each space in the subsequent rows. The same applies starting with one column and adding rows: initially 2 is added for each new row, but only 1 for each space in the subsequent columns.
The formula is in fact:
(columns.rows) + columns + rows
So, for the Farmingon matrix of 51 x 88 we get:
(51*88) + 51 + 88 = 4627
Once this base has been calculated, the non-clear terrain character values are accumumulated as indicated in
the table above.
Note that inserting a non-listed character as a terrain type subtracts 1 from the checksum instead of incrementing it. The map loads, but displays this hex as "Blocked" with its image greyed-out, an interesting quirk.
The values in the elevations block do not affect the checksum. Neither does any data in the place-names block.
Spaces in the hexside blocks do not affect the checksum. Other hexside character values are accumulated as indicated in the table above.
In Campaign Corinth you have to add 1559 to the map checksum value. Other games have other values, the list is
not complete :
Campaign Ozark add 1351
Campaign Franklin add 1653
Campaign Gettysburg add 1904
Campaign Peninsula add 1775
Campaign Atlanta add 1541
Campaign Shiloh add 1447
Campaign Vicksburg add 1776
Campaign Chickamaugua adds 1934
Campaign Antietam adds 1651
The checksum can be calculated either manually, or using a checksum calculator utility. This will be explained in a later 'making maps' page.