Battle of Britain Terrain Editing v2.10

Version 2.10 by PV

This is a minor edit to update the text for changes since 2008
to the BoB2 rendering system, and various web addresses and other
bits. I may have overlooked some things…

(Intro from V2.0:
This represents the most thorough revision since I first started this project.
The text is revised and expanded, lots more illustrations, and I hope a
very beginner-friendly detailed level of content.)


A Table of Contents

1) Disclaimer (I didn’t do it, you never saw me, you can’t prove anything!), and Introduction
2) General Information (Theory and Philosophy)
3) Things You Will Need to Know
a) Files and Folders
b) The Command Line Environment
4) Tools You Will Need
a) an image editor
b) Your computer
c) mtt2
d) Map Resources
5) The Terrain Textures
6) Editing Terrain Regions – how it’s done
a) Install mtt2
b) Locating a region to edit
c) Extracting a region for editing
d) Editing the pcx file
e) Saving the edited file
f) First compile test
g) Second compile test
h) Inserting your edit into the terrain
7) A compendium of notes about the editing process.
8) Using a Stack
a) How to build a stack
b) managing the pcx layer on a stack
9) Fartiles.bin
10) Terrain Height Editing
a) Simple height editing
b) Height editing with SRTM data
c) Preparing an edited heightmap for compiling
11) Object Placement
12) Now What? – modded terrain distribution
13) BoB Discussion Fora -community contacts, plus other useful links
14) Appendix – A catalog of a few mtt2 error messages and their likely cures


1) Disclaimer

I am writing this, not from a position of authority, but rather as a summary of what I have been able to glean of the operation of the terrain modding tools applicable to Rowan’s Battle of Britain, and A2A Simulation’s Battle of Britain II Wings of Victory. (To date, the editing process is essentially the same for both versions, with some minor differences in filetypes, which are noted when encountered.) Just so we understand that. I don’t have all the answers, and there is more to discover. This is rather a process of trial and error, back engineering, and technological archaeology (yes, we actually have the source code for Rowan’s BoB, so we are not entirely working blind, but we don’t have the full documentation, including quirks and work-arounds, for Rowan’s terrain building tool, mtt2.) For what I have learned of this process, beyond my own trial and error, I am wholly indebted to the information provided to me by those who have done this work before me. Much else I picked up via web forum discussions on the website fora at and, which at that time were the homes of the BoB Development Group, the BDG, a purely volunteer group which was formed to provide community support for Rowan’s Battle of Britain after Rowan Software folded.



The BDG was generously provided with the source code for the sim, as well as ancillary tools, and undertook to provide patches and enhancements to the orphaned sim. Since then, the software has passed to Shockwave Productions (now A2A Simulations) which produced the enhanced release BoB2 WoV, but through all that time, the BDG has persisted, and now that the commercial cycle for BoB2 is winding down, the responsibility for further patches and enhancements has reverted to us once again. In fact, as there seems to have developed some misunderstanding about the BDG, I guess I should also make clear exactly who and what we are. We are anyone who wants to provide enhancements for BoB, and BoB2, to their users. If you download this tutorial, use it to do some work you are happy with, and would like to share with the BoB user community, you are already most of the way to being a member of the BDG. Simply contact us via the A2A or SimHQ BoB2 forum, and we’ll be happy to welcome you aboard, and fold your work into a patch release.

Also, while there is much in here of use to established modding wizards, I have tried to make things simple enough that a beginner (and I mean an absolute beginner!) should be able to find their way about. I certainly hope so – I would like nothing better than to see lots of modders chipping away at improving this terrain. There is a lot of material here, unavoidably, as there is a lot of content to the terrain editing process, much of which is about overcoming the quirks of the editing tools. However, the overall concept is pretty simple, so you should try to see through the details to the general idea, which I hope comes through clearly. I think the best way to use it would be to read it all over once slowly, then just leave it open in a corner while you flail about, and pull it up and search it whenever you run into problems. I certainly don’t intend anyone to find the content overwhelming, nor intimidating. I wouldn’t like that at all. In fact, if I hear that anyone has been intimidated by this tutorial, I will personally see to it that a couple of large simmers come round to his house and break both his legs. So now we’re clear on that,
OK, let’s proceed…


2) General Information

“The problem with creating detailed terrain for a flight sim is all about memory size.” That is how I began the first version of the tutorial, and while bytes per penny have continued their relentless climb over the years since then, it still holds true, and always will, as our expectation of level of detail rises to easily keep pace with the advance of technology. In fact, at least for period terrains, where no tools yet exist beyond manual editing for the job of creating the planet of a previous era, when the hand of civilization lay far more lightly on the land, the availability of higher detail in rendering means more manhours per unit area to construct this terrain. While four years ago the notion of gigabytes of terrain data was not considered seriously due to hardware limitations, it is now unremarkable, at least for contemporary flightsims where a DVD of satellite imagery can be assembled essentially without human intercession. However, such material would require immense editing to remove the stamp of the 21st century.

So it is that for the creation of the land now almost 70 years gone, the essential issues are much as they were when I wrote that considering “the labour involved in terrain editing, terrain data must be greatly compressed, and it must be efficiently edited to represent the appearance of the world as it was. Rowan’s BoB world is about 740km square of 1940 vintage terrain, so they managed to solve these problems, though naturally compromises were involved.”

The theory behind the terrain engine of the BoB sims (and I guess MiG Alley as well, though I’ve never looked at it) is that terrain is characterized by a relatively small number of types (fields, woods, houses, etc), which repeat across the world. These types can be represented by a relatively small number of detailed terrain aerial photo images. By rotating the viewing angle in 90deg steps (three steps only, representing shadows facing east, north and west; a fourth step is achieved without causing south-facing shadows unnatural to a northern location by making an east-west mirror of the north image), four times the variety can be (sort of) achieved from the same number of images. The large regions of terrain can then be created by generating coding maps which determine how the terrain image files (referred to as “textures”) are to be cropped, and fitted together like jigsaw pieces. Generally, the different texture regions are separated by roadways, hedgerows, rivers or coastlines.

The coding maps contain much less information per gameworld-area than a high resolution photo image, so considerable compression is achieved. The coding maps are in fact stored in the game not as image files, but as six compressed vector-coded files which amongst them include both the texture coding and the complete height map data, and all together take up just 40 MB (and will compress to about 25MB). In addition, the photo images used for “painting” the terrain in the original Rowan BoB release were 32 files, totalling about 1.8MB. This makes a very compact and effective way to represent 550,000sq km.


3) Things You Will Need To Know

An introduction to your computer; under the hood with Windows.

a) Files and Folders

I said earlier that I have tried to write this tutorial as simply as possible, suitable for rank beginners, but it is easy to forget the level of computer inexperience of young people who have grown up with “user friendly” GUI-based operating systems, and never had to deal with things like a command line environment before. Questions about that on the BoB fora have alerted me to this deficiency, so I will provide an introduction here. If you know all this, you can skim it quickly and skip ahead, but it seems that much of this is news for most users these days, and there are a few goodies in here even for seasoned users, such as the DOS window PowerToy in part b). My comments are based on XP Pro, but are largely transferrable to other flavours of Windows.

First of all, for terrain work, you are going to have to be able to find your way around the folder structure of your machine, to locate files, note their size and modification date, move them, rename them, etc. For this, I recommend you get in the habit, at least in the folder structure you use for your terrain work (Explorer can remember different view formats for different folders), of using the Windows Explorer format which results from using the “Explore” rather than “Open” command:

This provides a split window view, with the folder tree on the left, to help with navigation:

(Notice the folder structure in this image, as I will be referring back to it occasionally.)

Next, go into the Explorer menu Tools > Folder Options:

and select View, then configure the list items, in particular, uncheck “Hide extensions for known file types” as follows:

Then, select the menu item View>Details:

this provides a text view of the file content of the folder, showing the full filename with extension, and filesize and created and modified dates. It is a much more compact display than the default “icon” view, and by clicking the titles (Name, Size, Type etc) along the top, you can have the list ordered by that item, toggling ascending and descending with each click. A right click on the title bar allows selection of more columns of information.

For terrain work, you will want to create a folder structure. You can see a bit of my folder structure in the images above, for all the various BoB-related projects I do, starting at “BoBWork”. You likely won’t need anything that complex, but at the least you will want a folder for mtt2 (much, much more about that later) and subfolders beneath it for each terrain section you edit. To do this, in the Explorer left panel, highlight (left click) the folder above where you want your folder to go. To place a folder on the top level, highlight the Drive letter. With this item highlighted, go to the top of the window and left click on File, mouse over New to reveal the submenu with Folder as an option:

Note that this series of menus is only available when a folder is highlighted in the Explorer left pane. When you click on Folder, a folder icon will appear in the Explorer right panel, with the name “New Folder”, available for renaming.

File moving and copying are so basic to computer use that I hope I don’t need to explain it here, but at least, please be sure you understand the difference between moving and copying a file. Mostly we will be copying, and it will generally be necessary that the original file is still in its original location, or you will get problems like no terrain left in your game install…

b) The Command Line Environment

A “command line environment” is what you get when you open a “DOS window” on your machine (“DOS” stands for Disc Operating System, and is in this case short for MSDOS, which is what MicroSoft called its Operating Systems before they were called Windows). The Rowan file manipulation tool mtt2, which does many other things besides editing terrains, is a program which must be run from the command line environment, so you need to be familiar with how that works. So, first, you need to be able to open a dos window. In XP, that is usually done by looking in the Accessories section of the Start Menu/All Programs list for Command Prompt, however, if you check the bottom of this page (jump down) you will find a link to a handy little Windows PowerToy widget which will open a command line window for you, which will operate from the folder you need to be in (command lines are always associated with a folder location, which is shown to the left of the > sign, in the window text box, so you always know where you are). When you’ve installed the PowerToy, just rightclick on the folder you want, and select Open Command Window Here. Without the PowerToy, which, alas, only works with XP, depending on the windows version you have, your command window will open at C:\Documents and Settings\YourUserName> or some other location, and you will have to navigate by DOS commands to get to the correct folder. That is a pain, and rendered completely unnecessary by the PowerToy. The alternative in these cases – i.e. Win7 – is to make desktop icons of command window links opening in all the folder locations you want, not nearly as nice a system as the PowerToy.

The DOS window in default form is white type on black, 80 rows by 24 columns (there is also an option to have the window open as a full screen. As you will be working among about five windows most of the time, you definitely don’t want that). This is a rather claustrophobic display by today’s standards. The first thing you want to do is reset your window to something more comfortable. Right-click the top of the window frame to access the main menu, and select Properties.

I like a 95×65 character window, which works well on a screen 1152×864 or larger. The extra width accommodates the typical line length of mtt2 output lines. Give yourself a whacking huge screen buffer – it doesn’t take much memory. You may need to review a screen output of 5000 lines from one operation. Screen buffer width should match window width. You can play with the font and the screen colours, as well. I always use Lucida Console in 12 point (the DOS window requires a non-proportional font). A white screen with black print is always easiest on the eyes, but if you are in the habit of doing a lot of text-window work, it is sometimes useful to colour code your screens so you can keep track of which is which. I’ve been leaving the dos window white-on-black so I can find it quickly among all the notepad and wordpad windows I often have open while editing.

OK, now for how the content is presented, and interpreted, on the dos window screen. Here is an example using mtt2 on my machine:

C:\BoBWork\mapstuf\mtt2>mtt2 -dqbr 185 216 196 227 -r pal.pal -w terrain1.pcx -w terrain1.tga

What does this mean? Well, all the stuff to the left of the > sign is location information, telling you in what folder the window is operating, just as it is written in the Address bar of the Windows Explorer display. It is written by the computer. Here, it is the mtt2 folder which I have highlighted in the image at the start of this section. That is my mtt2 working folder.

Next, the > character itself is called the prompt (or command prompt, or C-prompt), and it means the computer is waiting for your input. When you type in a DOS window, your type appears right after the prompt.

Immediately after the > sign is a command, which is the part you write, and in this case the command I’ve written is mtt2, which is short for mtt2.exe (the file extension is not required). Some DOS commands are called “internal”, which means they are built in to the DOS command program, but as well, any executable program, such as mtt2.exe, which is present as a file in the current operating folder, can appear as a command on the “command line” of the DOS window. The command is a call for the computer to execute the program.

After typing out the line, by hitting enter, you cause the computer to immediately run the program mtt2.exe, invoking all the “command line parameters” which appear further to the right on the line. If the program file is not present in the current operating folder (as when say you type the name wrong), or if it is not an executable file, ie not a program (an executable file has a filename whose extension is .exe, .bat, .com, or a couple more new ones I forget), then the computer will respond on a new line, with an error, rather like this:

‘zork’ is not recognized as an internal or external command,
operable program or batch file.

The “command line parameters” are all the other characters on the line after the command, ie -dqbr etc. They have particular meaning for the program, and help tell it what in particular you want it to do. mtt2 is written in unix style, which means its parameters are preceded by a minus sign, and can be clustered. The string (set of characters) “-dqbr” could be written -d -qb -r and would work the same, but are clustered to save typing (unix was written by very lazy typists, unlike some earlier languages which insisted on painfully verbose command strings). Microsoft DOS style commands always used a forward slash where unix used the minus sign, so a typical dos command with a parameter would look like

C:\BoBWork\mapstuf\mtt2>ipconfig /release

But with any luck, you won’t need to invoke any DOS commands, so we don’t need to go into this any further. What you do need to know is that when you type an mtt2 command in the DOS window, and hit return, the computer will execute the program, reading in all the parameters you’ve written, and it will print out its progress on the screen. When it’s finished, if all has gone well, it will print a line showing the current folder location and ending with the > command prompt. You can then use the scroll bar to look back through the often hundreds of lines of output, to see if there were any errors, which will tell you where to look on your terrain-building image files to correct the errors.

There is much more to the world of the command line interface, but what I’ve covered here is most of what you need to know to work with mtt2, so we’ll leave it for now.


4) Tools You Will Need

a) An Image Editor

The first requirement for terrain editing is a good image editing program, or perhaps several, in order to find all the features which are required. I am able to use the gimp for most work, but there are a few things I’ve not been able to get it to do. I’ll say more about that later. There are several requirements of your image editor. First, it should be able to open and save .pcx files, which are the format used by Rowan’s terrain tool. To edit height maps, your editor must also be able to read and save Targa (.tga) files, or, as we have discovered, “portable network graphics” (.png) files. (I’ll say more about this later.) Second, it must be able to draw straight lines one pixel wide, with no overlap, and no gaps, at any angle, easily and reliably, as this is a lot of what you will be doing. Third, it must be able to show you the index assignment of colours in 256 colour images – the .pcx files used are 256 colour images, and each colour has an index number, from 0 to 255; you need to be able to determine the index number of any pixel in the image. Fourth, your editor must be able to show you the location of any pixel on an image, in xy coordinates, as you will need to enter this information into command line parameters, and locate pixels from mtt2 output. Fifth, it is most convenient if your editor is able to handle multiple layers in an image, with variable transparency. This allows you to lay historic maps or aerial pics, BoB terrain maps, BoB height maps, and BoB ingame map screen captures over each other in a stack, and by varying the transparency, edit a map as if you are tracing over a drawing. You can thus achieve historical accuracy with your terrain.

Some image editors which I know of which satisfy most of these requirements are Photoshop (costs bucks), PaintShop Pro aka PSP (costs not so much bucks) and the gimp (free), which of course is what I use. You should be aware, however, if you are contemplating trying gimp, that it is not terribly well supplied with help files. Some aspects are well supported, but others are “not yet documented”. Fortunately there is a separate help manual available online, and I have given a link for it at the bottom of this page. Beyond that, the problem with the gimp version I have (upgraded to v. since I first wrote this file, but I still have this problem) is that it can read targa files for height maps, but it doesn’t save them in the form that mtt2 (the BoB terrain tool) likes, so as a result it will create 5km high cliffs everywhere. Until recently, this has been a great stumbling block for getting into terrain editing without committing to spend money on a graphics editor, as there are apparently many targa format variants, and gimp, so far as I’ve been able to discover, does not write the one that mtt2 wants to see. (I had been getting around the problem by converting gimp targas using an editor which was bundled with my scanner). Fortunately, although it is not mentioned in any of the sparse documentation provided by Rowan, it has been discovered by the ace terrain modder who came on board after the release of BoBII, Hurricane Hicken, that the PNG file format works as a direct alternative to the Targa file in encoding height data. How did he figure this out? I have no idea. But I have found that while gimp is as incapable of reading the .png files mtt2 creates as it is of writing .tga files mtt2 can read, it can do the inverse – reading mtt2’s targas, and writing mtt2-compatible PNGs. So the best free method of handling the mtt2 heightmap files is to have mtt2 write them as .tga, which can be loaded directly into gimp for editing, but have gimp write PNGs for loading back into mtt2.

b) Your computer

Oh, and I should also make a note here about your computer spec. I’ll give this a quick 2012 update… Generally, a computer which will run BoB2 will easily handle terrain editing, but if you are ambitious, you can and may want to open a large region of the terrain for editing. I have often edited regions 20 Rowan tiles on a side, which means 5120 pixels on a side. this can easily run to a workspace of 400MB or more, and to avoid thrashing the hard drive, you need at least a Gig of RAM to do this comfortably. The standard seems to be about 6 Gig for new machines as of this writing, so that should be adequate. These days, running BoB2 comfortably really wants about 2.5GB, so as I say, if you can run the program, you should be good for editing. Make sure to check your image editor’s RAM work area allocation, and keep it larger than the largest working file size, so no disc swapping is required. For gimp, the default used to default to 64MB, some years ago, which is way too small. The latest version I have doesn’t seem to have that setting anymore, I guess it just takes what it needs. Also, the file size in RAM is always larger than the size written to disc, so don’t go by the latter – gimp shows the true working file size in the bottom left side of the image window:

Note that this xcf file (gimp’s native working file format) is 138MB on the drive, but opens to 613MB in RAM, for a 14 layer stack (the stack is mostly of small maps or aerial photos which show the detail of a small section of the terrain. If all 14 layers were the full 7168 x 4352 pixels, it would be vastly larger yet). Thus I had my working RAM space for gimp set to over 700MB, when I ran that version.

Also, you will very rapidly build up a large archive of your work. As you edit, you want to save often (using, for instance, sequential numbers at the end of your filenames) so you can go back two or three steps if you need to, and the working files in image editor format, with multiple layers, can run to a couple of hundred Megs. My mtt2 work area currently runs to 7.5 Gigs on my drive, so you want to have lots of drive space available. …And, you are going to want to have a means to make backups of your work on some external medium, in case of computer failure. These days (2012) I use a 320GB external USB SSDrive, and back up after about 4 to 6 hours work. I will typically save the mtt2 folder with all its subfolders, plus my terrain research material folders, where I am constantly acquiring maps and photos for areas I want to edit in future.

Also see in section d) Map Resources for comments on a scanner peripheral.

c) The Heart of the Beast: mtt2

All terrain height and texture location coding work is done using the tool that Rowan originally used, a command line program called mtt2, which can currently be found in a zip  here, or on BOB II google docs here (open the link and click CTRL-S to download the whole zip). It contains a .doc file worth reading, though much of the many functions of mtt2 are not well enough described to be helpful. I find I mostly use the .doc for recalling command syntax. A (not terribly lucid) description of the program can be found here. It probably means something useful to someone with programming skills. This description came I think from Rowan, and while the program appears from this description to have some association with Microsoft Developer Studio, Osram tells me it is a Rowan in-house tool which was simply created using MS Dev Studio. I can tell you that what I know about mtt2 is a small fraction of what I don’t know about it, as you will see as we proceed.

To give you an idea of all the things mtt2 deals in, here is the command line help which you see if you enter mtt2<return> without any parameters. As you can see, there are a LOT of possible things you can ask this program to do. But we won’t, here, because I don’t have a clue what most of them are about. For our purposes, we will use a small number of parameter sequences which were revealed by Rowan, and we will use them like magic incantations, without really knowing very much about why we use them or what exactly they are doing, except that this will get us the results we seek.

d) Map Resources

If you are going to mess with the BoBWorld map, you should have a good idea of what you are trying to do, and if it’s to be for public release, and inclusion in the canonical public terrain set, you should do your best to make your edit as accurate as you can to the world of 1940. The web is a great source of such material, but you will also benefit from hard copy materials. For instance, you will find that a highly detailed map of Britain is indispensable – I use a Great Britain road atlas book with 80 26x40cm pages of map, and both Michelin and IGN 1:100,000 maps of northern France. Visit large or specialist libraries, map stores, etc. Collect as much information as you can.

In the past, I have pointed in this document to the TARA Aerial Reconnaissance Archive website, which has provided a wealth of useful imagery for the creation of period terrain. This resource now resides at the “Royal Commission on the Ancient and Historical Monuments of Scotland” website, Currently it is only of use for sites on the continent side of the Channel. This site is a real treasure if you are thinking about working on LuftWaffe french airfields: or in English translation here. (It has been reworked since I first put this note in, and last time I visited, navigating was decidedly nonintuitive.)

Another good resource for period maps of England is this website intended for documenting British postal codes, it uses maps ranging from 1936-47 or so, of an intermediate resolution which is somewhat useful for period mapping. I also make use of the Ordnance map site for altitude information. Although we can now get moderately detailed Space Shuttle topographical survey data (see Sec. 8 on heightmapping), that doesn’t provide the necessary detail for steep edges like coastal cliffs and river channels, so these need to be done by hand with the help of hi-res topo contours from the Ordnance site. Other good sources, added in 2012 revision: Google Earth now includes a wealth of old B&W aerial images of England from 1940-50, accessible via some sort of switch. I haven’t run G.E. for a long time, as I found it spreading out and taking up a lot of space and time on my machine, doing updates without permission which interrupted other programs, etc., so I can’t tell you the details, and I have found the same material (though much more difficult to navigate and capture) at this site . Also try this site, which is currently expanding: Another source for aerial images of England is Luftwaffe reconnaissance photos, which can be found online in a few locations; try these: , , or google for more. And this site has a vast collection of period Ordnance Survey maps of Britain, and has become a go-to place for me, best used in conjunction with aerial photos if available:

Finally, if you are collecting hard copy materials, they are most useful if they can be digitized so as to be layered onto your editing stack, and this requires scanning them. It is possible to have this done at a local copy shop, and many modern gadgets are multifunction scanner-printer-copier-faxes, and if you have access to one you can scan stuff and mail it to yourself in a single step, but by far the most convenient when you are wrestling with getting maps onto your stack is to have your own scanner sitting on your desk, where you can rescan if you find problems. Scanners are fairly cheap these days, but not trivially so, and they do take up a fair footprint, but if you want to really dig into this hobby then the ~$150 is not unreasonable, and you can always say you need it to archive all the old family photographs (I said that when I got mine four years ago – someday when I have time, I will get around to doing it, if I still have a computer and a scanner and the photographs haven’t all decayed from old age and neglect…)


5) The Terrain Textures

The texture files BoB and BoBII use for painting the terrain are located in the subfolders Landmaps and Landmap2, though I believe only the latter are used. The files have names of the form “img00xx.yy[y]” where xx is a number from 00 to 31, and yy[y] is the filetype extension. In stock BoB-1, yy[y] must be “x8”, which is Rowan’s in-house image format. It is not read by any image editor, and must be converted using the file conversion ability of mtt2 before the files can be edited. Fortunately, for versions of BoB-1 patched with BDG updates, and BoB II, other file formats are supported, so it is not necessary to convert the files to view them. In BoB-1 BDG, pcx format is used. In BoB II, dds format is used. DDS is relatively new, but most full function image editors support it. If yours doesn’t seem to, check the makers’ website to see if a plugin update is available.

Actually, the usage is more clever than I’ve indicated. In BDG BoB-1, when painting a texture, the program first looks for .pcx files; if none are found, it falls back to .x8. In BoBII, at least for terrain textures, only .dds is acceptable, but for many (most) other image files, the program will first choose .dds, but falls back to .pcx and finally .x8. The texture files must be square, but beyond that, there is some latitude on how big they can be. Some BoB1 textures were 256 pixels on a side. The latest BoB2 textures released in 2010 are now mostly 2048 pixels on a side, and the result is crisper detail at low altitude on the terrain (but put a much greater load on the video card).

Anyway, you can edit the texture files if you want, but creating terrain does not require touching these files at all. Editing texture files can change the colour, saturation, or overall appearance of the photoimages, but will not have any affect on where they go in the game. Note also, as I mentioned above, the images are dropped into the terrain in four orientations, three 90deg steps plus a mirroring. Thus, you don’t want to have strong shadows showing in your image files, as the shadows will be rendered pointing in all directions. This is a problem with the original Rowan BoB-1 images, as some of them include tall trees, and all the pictures were taken in strong summer sunlight, so we edited some of the worst offenders to lessen this problem, for the original BoBII release textureset. It should also be pointed out here that as of about 2010, we have settled on a more or less permanent set of textures (until such time as we can insert extra ones), as we have been spending a lot of time recently inserting 3D ground objects (buildings, cars, etc.) into the terrain, and they need to match the underlying terrain testures – don’t want a building placed over bushes or hedgerows shown in the underlying texture, for instance – so we are not too keen on changing the textures now. If a change is made in future, it may be to revert to textures with only ground painted, and all else, including shrubbery, hedges, along with buildings and whathaveyou, to be represented by 3D objects.


6) Editing Terrain Regions – how it’s done

a) Install mtt2

Right. Having fetched the file from section 4 c), you first want to create a folder for it. You can see how I’ve arranged my folders (section 3 a), but you can put yours anywhere. Call it “mtt2”, and get in the habit of storing each terrain project in subfolders you create under that. Unzip the mtt2 pack into the folder. It will unpack 9 .pal files, of which only landlow.pal is of interest, and only for one instance of use, which we shall come to shortly. The rest are of no importance for our purposes, though if you spend some time probing mtt2 you may be able to determine some purpose for them. I haven’t bothered. Otherwise, you can delete the unzipped copies, if you like.

There are six other files in the zip, but only three are of interest. There is the mtt2.exe file – the program itself (currently named mtt2_0207.exe in the zip, as we needed to keep track of modded versions; you can rename it to just mtt2.exe if you like, so it corresponds with the name I use for it in the tutorial); and the accompanying .doc file, which is mostly useful as a command reference, and for its hints into the many other uses of mtt2 which we don’t know and won’t pursue here. And, there is the BoBPal1.pcx file. In the original mtt2 zip from Rowan, there was a BoBPal.pcx file, which had many problems, but to avoid confusion, I’ve replaced it with the slightly differently named and much improved one here, which should be dated July 2012. It contains a lot of information, and you will need to refer to it constantly. I will have much more to say about this file later. For now, I will just show you what it looks like blown up to x2 size, so you can easily read the content printed in the image:

Note: the image as displayed here is a .png. The file you will need to use is the original .pcx file, as the .pcx format contains important information in its colour indexing, which is stored differently in .png, but most browsers won’t display .pcx files in default configuration, so I’ve converted to png to display it for the tutorial. (Recall that the pcx files have 256 colours, and each one is assigned an index number from 0 to 255.)

The other three files from the zip, one .bat and two .res, we will not be using, so you can delete the unzipped copies, if you like.

In order for mtt2 to be able to do anything with the terrain, it must have the BoB/BoB2 game terrain files in its folder to work with. There are six terrain files, found in your BoB or BoB2 install:


and as well we will need, for one initial operation, the file GridData\LOWCOL.GRD . Copy all these files into your mtt2 folder. They will typically add up to a little over 40MB, with the current level of complexity of the terrain. I hope that you will do some edits which will contribute to making these files larger, and provide more detail to the map. These files will occasionally be updated with new patch releases. If you are working on your own terrain project, be sure to update your mtt2 folder with the latest patch release versions as they become available.

Now, during the edit process, you will be overwriting those six files, and testing them by overwriting them over the originals in the game folder, so you should now make a folder (it can be a subfolder under your mtt2 folder), and store another copy of the six original files there, so you can get them back any time if you mess up. I recommend that you include the date of the fileset in the name of the folder. I now have a folder labelled “terrain sets” which contains many dated subfolders containing the six terrain files saved at major development points over the last few years, including at the point of each public release. If, as occasionally happens, it is discovered that something has somehow gotten broken on the terrain, I can go back to find the last good terrain set, and it only takes a short while to step through repeating all the subsequent upgrades to yield a repaired and up-to-date file set. (It is also always a good idea to back up your work regularly to an external medium, like a CD or DVD, or thumb drive, (as of 2012, I use a little 320GB USB-driven external SSDrive) depending on how big your work folder is. Best is to back up every few hours of work time. You don’t want to ever find that you’ve lost eight or more hours of terrain work.)

Next, we need to create another map file for reference purposes. Here you will get to make your first use of the mtt2 program, and all the information I have provided for you. Don’t forget to start with the “Open Command Window Here” Powertoy to open the DOS window at the folder where you have put mtt2.exe . In earlier versions of this tutorial, I included a nested copy of the tutorial I learned from, by a Rowan staffer who frequented SimHQ as “Not Enough Red” (“NER”). Subsequent developments have made his work somewhat dated, so I have rewritten it, but I still follow the outline of his document. And here, I will quote NER’s instructions, from his tutorial, as he puts it quite well…


Wow!. Look at that!. the aliens have come and turned England upside down, (or maybe this is how the Australians see us) Why is it upside down? Don’t ask me. I just work here.

Anyway. This is the entire BOB world… its pretty big. Something like 500k sq miles…
See how the south east of England is “speckily” compared to France? the “speckily” area’s are the parts that were hand drawn by those dedicated and underpaid people at Rowan.

Anyway. You will see why this bobworld.jpg is so handy.. in a second..

So how do I get this handy thing?
Good question, and one I was just about to answer,

Ok, Switch to your c:\mtt2 directory (or wherever) and type in the following command.

mtt2 -r lowcol.grd -cx64y64w512h512 -r landlow.pal -w bobworld.pcx

And there you have it.. Bobworld.PCX has been created in your c:\mtt2 directory…

That will do it! How that command works in detail, I don’t know, but fortunately we don’t need to, we just need to be able to use the image file that’s been created. That is also the only time we need to make use of the landlow.pal file, so you can delete it from the folder if you like. Now, one more item: in this tutorial package is a file newpal.pal. Drop that file into the mtt2 folder as well, and rename it pal.pal. OK, that pretty much completes the installation. Now, let’s discover how to find the initial numbers you need to know to edit a region of the map…

b) Locating a region to edit

Right, now it’s time to open up your image editor, and make use of its ability to show you the location of any pixel on an image, in xy coordinates, as was noted in the editor requirements (Sec. 4a). Let’s say, following NER’s original tutorial, that you’d like to edit something in the region of the Tangmere RAF airfield. Now, refering to your Big Map of Britain (you did go out and get one, didn’t you?), you can look up Tangmere in the index, and find that it is on the south coast, just east of all those little inlets on the mainland north of the Isle of Wight, and barely east of the point called Selsey Bill.

So, now open BoBWorld.pcx in your editor, and remember, although south is up, east is still to the right. So find the area around Tangmere on the map (you will probably want to zoom in), and read the coordinates for that location. With the odd mirroring and rotation, it is a bit disorienting at first, but you’ll manage. You should first see that the eastern pixel at the point of Selsey Bill is at 187, 207. Tangmere is inland and east of there, so that’s right and down. NER would like us to select a wide chunk around the Tangmere field, so he specifies the square enclosed by the corners 185, 216 and 196, 227. That is 11 pixels on a side. All we have to do while preparing to select a region of the map, is view BoBWorld.pcx like this and make note of the corners of the region we want to edit. NER’s region is square, but any rectangle is allowed.

Here I guess is the best place to provide some details of the construction of the BoBWorld. (This is illuminating, but you don’t need to know it, so if you’re not interested, skip this paragraph). The image you are looking at is 512 pixels in each direction. My current best estimate, based on the logic of binary computer systems, is that the extents of the map are intended to be 738km. This is based on the appearance in the BoB code of the “BoBWorld coordinate unit”, which appears to be 1.1cm (I guess it started out as 1cm and was inflated at some point). The connection is that 2 to the 26th power is 67,108,864 , and times 1.1cm =738.1975km . The way it all goes together is that each of the 512×512 pixels in the BoBWorld map represents one 256×256 pixel “tile” in a pcx file, so each pixel in the BoBWorld file is (738.1975)/512=1.4418km on a side (2 to the 17th BoBWorld units), and each pixel in the pcx file is 738.1975/(512×256)=5.63 metres on a side (2 to the 9th units). These numbers seem to compare well with values measured on maps and referred to features on the BoBWorld pcx files, however the BoBWorld covers sufficient area that slight errors must develop due to the curvature of the earth. (Careful measurements at small scale in France suggest a pixel size of 5.7 metres which would make the map 747km, while measuring features across the extents of the whole map yield a number closer to 720km.) These sorts of discrepancies are to be expected, and you aren’t likely to ever find yourself editing a large enough region for it to be a major issue. The bottom line is that the smallest feature you can hope to mark on the BoB terrain is 5.6 metres on a side (18 feet).

OK, now we know the numbers we need to extract our region to edit, let’s try it.

c) Extracting a region for editing

This is a new project, so we want to create a new subfolder for it, under the main mtt2 folder, with an appropriate name – you want a name whose meaning you can remember when you come back to it in future years (BoB terrain editing is a lifetime endeavour, right?). For this one, “tutorial” will probably do nicely, but for future projects, name the folder after the main feature you are editing. Next, we want to open a command window at the mtt2 folder (for our work, we will always only open the command window in this folder), and extract the region we are going to edit. To do this, enter the following command, exactly as it is shown here (just the part after the > sign):

[whatever_folder_path]\mtt2>mtt2 -d4qbr 185 216 196 227 -r pal.pal -w tutorial1.pcx -w tutorial1.tga

[approximate breakdown of the parameters:
-d show text telling what you’re doing;
-d4 at the 4th level of detail (1 to at least 9, default is 3, but always use 4 or higher);
-qb extract something from the terrain files;
-r read the following object (in this case, the terrain fileset);
coordinates are X Y largerX largerY;
-r again, read the palette file to know what colours to use (if you forget this item, you will get a file that looks the right size but is totally blank);
-w write the following file – mtt2 knows what sort of content to write based on the file extension – height is always tga, for instance.]

Hit return, and mtt2 will whirr and click for a second, giving a quick play-by-play of what it’s up to, then exit, and if you look with your file manager (which you should have open on the screen, as you will be using it constantly) you will see that the files tutorial1.pcx and tutorial1.tga have been created in your mtt2 folder.

Before you do anything else, you should right-click the menu bar at the top of the Command window to activate the edit>mark function and highlight the command you’ve just entered, with all its parameters:

With the text still highlighted, re-enter the menu and select edit>copy. Now open notepad and paste the line into it, and save the result as the file tutorialXY.txt in your new \tutorial folder. You now have a record of the coordinates of your new files.

Next, copy (not move) the two files from the mtt2 folder down into the \tutorial folder. You will do your edits on the files in this folder.

d) Editing the pcx file

OK, now let’s have a look at the files you have extracted. One is a .tga file, which contains height information. As we follow along the path of NER’s original tutorial, we aren’t going to do any height editing on this region, but it is necessary to have the heightmap file written, as it is required during the insertion of the data back into the terrain fileset. The other file is a pcx file, which contains the land use information, and this is the one we’ll try tweaking. So let’s see what we’ve got. Open the copy of tutorial.pcx in the \tutorial folder, in your image editor. You should see something like this:

This is a little chunk of land usage map, surrounded by a bright square of magenta. The magenta is called “mask” colour in the Rowan system, and is “explicitly ignored” on a land use pcx (I’m not exactly sure what that means in practice, but splotches of magenta on the map are definitely ignored if they occur within one colour region and don’t interfere with any lines). The image shows the Tangmere airfield and its two runways in bottom centre. What has happened is that each single pixel in the BoBWorld.pcx image has been expanded out in this image to a “tile”, 256 pixels on a side, and the surrounding magenta is also 256 pixels wide ( – that is the only apparent use for the magenta – it shows you at a glance roughly how many 256-pixel tiles there must be on the image). Unlike the BoBWorld.pcx map, this image is “right way up”, ie north is at the top. Each of those coloured blobs on the image codes for a certain terrain texture image to be used. You can compare the colours with the key in the BoBPal1.pcx file in Sec. 6a to see what is being coded, ie there are large amounts of that bright green, which you will see is designated as “wood” in the key image. This is the colour for the raised forests (which may become regions of 3D trees during the publication lifetime of this version of the tutorial). In the lower left the little spots of blue and grey are “city dense” and “city sparse” respectively. (The strip in BoBpal1.pcx labelled “31”, with four purply colours, shows colour codes I added as they were left off the original colour map. They have been enlisted for textures to be planted as French farm fields.) Pretty much everything else is farm fields of one sort or another, except for the “lawn” grass used for the airfield. If you zoom in (on your pcx, not the jpg I’m illustrating this page with, it doesn’t have the resolution to show them), you will see that at every point where a boundary between colours changes direction, there is a white dot. These dots are the key to the whole compresson system used by the Rowan terrain system. As NER says “Imagine these as Pins in a piece of paper, with bits of string between them. (they “pin” the outlines into place)”. These dots are officially called “control points”, but I mostly just call them the dots. There are also usually (but not always) lines connecting the white dots. These must be drawn using the colours listed in the BoBPal1.pcx image as OUTLINES, and as you see there, the reddish ones are roads, greens are either railroads or hedges, and blues are rivers or “fake” (much more about the latter later):

Areas on the image must use the other colours, called FILLS. (The Fills are further divided into sections on the palette map, labelled Grass, Fields, Spreads, Roughs, Populated Areas, and Specials. Unfortunately with the current standard texture image set supplied with BoB2 patches, those designations don’t mean much; Grass, Fields, Spreads, and Roughs all use pretty much the same sort of hedged-fields-and-thickets image, with currently the exception of index #4, the lawn, #16, the rough pasture/moor, and #15, the Woods. The “31” colours are also Fills. They are called 31 because the first one of the set has colour index number 31.)

Only the positions and height values for white dots are recorded in the BoB2 terrain files, along with information on the index numbers of the colours surrounding the dots. This is enough information to fully and uniquely construct the terrain, if the image has been built correctly. Any error in the pcx file which gets compiled into the terrain files will cause confusion for the terrain renderer, which can cause odd behaviour of the sim, and may make it difficult or impossible to extract that region again to correct the errors. It is crucial to stamp out any errors in your .pcx files before they get compiled.

OK, following on with NER’s tutorial, he proposes to insert a shape into the terrain, which will spell out the letters SIMHQ, which is the name of the web forum where the BDG was first formed. He shows how he starts out to do it with this image

The airfield has undergone some edits since NER wrote his tutorial, but never mind that, we’re only interested here in the letters he’s put down. He has used the BoBPal1.pcx file as a source, and making note of the legend, has selected an outline colour (in this case, “B road”), using the eyedropper tool, to use for drawing the lines in his image editor, then added white dots at all the corners.

Now, first of all, in order to draw lines which are acceptible to mtt2, you must search about and find the right tool in your editor. For gimp, the trick is to select the pencil icon, and select the single pixel “brush” in the “Brush Dialog”; then click on the first point of your desired line on the image, and hold down the shift key while clicking on the second and any subsequent points. This should result in straight lines between the points, which are one pixel wide. I believe there is a very similar selection process for the single pixel line tool in Photoshop and Paintshop. The lines must have no gaps, nor can they have pixels making any part of the line thicker than one pixel wide. Borrowing from another tutorial, that of DonnyBrooke, the BDG member who introduced me to terrain editing, in the following image

the circled region of the upper line has pixels side by side, which is not acceptable You will get “lost my way” errors, when compiling (the most common type, you will see a lot of them no matter how careful you are). The required line is shown in the lower section. A second example shows triangle shapes

these are also not acceptable, and again the lower line shows the required appearance. The idea is that travelling along the line from any pixel on the line, there is only one adjacent pixel which is also part of the line, and there must be at least one, or else a white dot to end the line. Generally, this should not be a problem if you select the correct drawing tool – it should always draw lines as required by mtt2. If that were not the case, doing these edits would be pretty much impossible because of all the little corrections. If your editing program does not have a tool which draws single pixel lines correctly, you must find another one, as the work load will be insurmountable otherwise.

The easiest way to draw a complex shape is to hold down shift and click along forming the line segments, then go back and add the white dots at each change of direction.
So, the next step to consider is how to attach lines to the white dots.
To understand what the rules are there, first consider the pixels
which surround a white dot:

The rule is that no two adjacent numbered pixels can both be coloured with a line colour. Thus, there is a maximum of four lines which can attach to
any white dot. This explains the good and bad columns in the following illustration from NER’s tutorial:

This should be enough information for you to attempt, if you like, to imitate what NER has done in his example.

There is still lots to do. The next thing that mtt2 will not tolerate is any dot or linked set of dots, which do not then connect by further lines back to the edge of a tile. To elaborate, you see the map is divided into a grid, by white dots every 256 pixels, in both x and y. Even on open ocean, where there is nothing else going on, there will be dots marking out the grid. These dots are the only ones on the entire map that are not required to be connected by a line, or by a boundary between colours, to other white dots. You can think of them as the Cardinal Dots. When you extract a region from the terrain for editing, it is dispensed as tiles (the smallest area you can extract is one tile, 256 pixels per side), with Cardinal Dots in the corners. Now imagine lines linking those corner points, north-south, and east-west, along the tile edge. If any land use boundary crosses one of those lines, it must have a white dot at the crossing point. This anchors the boundary to the terrain. The BoB renderer figures out how to build the terrain by working out where each white dot is, relative to the edges of the tiles, by following along the land use boundaries. While processing, it often throws up error messages which start “lost my way…”, meaning it can’t figure out how to get from a particular white dot to the edge of the tile it is on. The worst case is when a linked series of dots make a circle which doesn’t link with any other line, nor the edge of a tile. In that case, the program will “feel” its way around the circle, over and over and over, until a watchdog notices that it has consumed huge amounts of time without accomplishing anything, and kills the program… or sometimes it doesn’t. It can just hang. In any case, as of yet the program is not able to put up the message “help, I’m going round in circles”, so the best indication that this is your error is that the program fails without telling you anything at all.

At any rate, the example edit that NER has done has several closed circles not connected to a tile edge, so the next thing he must do is fix that, and thus this next image:

The blue colour he’s used to link all his “islands” together is #153 “fake” which you will find in the bottom right hand corner of the BoBPal1.pcx image. This line type is very useful, as it satisfies mtt2’s requirements without causing anything to be drawn on the terrain. It has useful properties: mtt2 understands that it can be used for linking dots required for defining height on an expanse of terrain, in fact it is usually used to surround airfields and ensure that they are flat. Basically, a string of dots linked by fake line will usually be treated as a ridge, or a contour – the fake lines will be used as the edges on polygons built from the height info of that region. This makes fake colour the best choice for drawing height contours. Well, we’re not concerned with height here, we just want to make our shape pass mtt2’s compile test.

A further note must be made here about the tile boundary grid. mtt2 is very fussy about how lines are drawn when near the boundaries. I’ll quote Donny Brooke again:

a.  Whenever a line crosses one of the grid “lines”, a control point must be placed at the junction as in the figure below.  If it isn’t, you will get a “lost my way” error when you try to place your changed drawing back into the DAT files.

b.  The next is a little “iffy’, but it is probably a good idea NOT to place lines or  pixels on the 256 control grid lines.  Always approach a 256 grid control point at an angle.  I don’t know if this is entirely true, but it seems to work.

I tend to be even more conservative, and put at least two pixels on each side of the grid line at diagonal or steeper approach.

NER’s final step is to use the bucket fill function of his image editor to add a new land use texture assignment to the bodies of the block letters he’s written:

Looks like he’s chosen the “town dense” land use colour, so the letters will show up on the field as a bunch of buildings. If you are following along, edit your file to match his (more or less).

e) Saving the edited file

The edit is now complete, so the next step (unfortunately not necessarily trivial) is to save the image. As we haven’t (hopefully) messed about with the type of image nor its palette index, your image editor should still consider this a 256 colour indexed image, and it should agree to save it as a pcx file, the same format as the original file. Now, for this first trial save, DO NOT choose the “save” option which will save over your original pcx file. Rather, choose “save as” and give your file a new name. Our original file is called tutorial1.pcx, so we want to save this one as tutorial2.pcx, alongside the original in your “tutorial” project folder . If, during the save process, your editor asks if it can “build an optimum palette”, or “strip off unused colours”, or worse “save as RGB” say NO. We must end up with a pcx whose palette index has the same colours in the same order as those generated by mtt2 during the extraction, or the land use assignment will be totally muddled, and mtt2 will simply reject the image for compile. (The colours themselves don’t matter, in the sense that we could have used a completely different set of colours, and it would work the same, as mtt2 will only be looking at the index number of the colour to determine what to do. What is important is that we don’t allow the correspondence between colour and index number to change during our work.)

By the way, a minor caution: when we extracted the pcx file, we told mtt2 to use the palette file pal.pal, which is part of the tutorial package and lives in the mtt2 folder. Your image editor will probably also have its own palette files, which may also have the .pal extension, but they almost certainly will have their own format, and won’t be compatible with the mtt2 .pal files. Generally they are kept in the folders of the image editor installation, and aren’t a problem, but your editor may offer to write a palette file to your work folder. Again, just say NO. (If you ever lose your pal.pal file, mtt2 can extract one from the BoBPal1.pcx file, or any other land-use pcx file you’ve generated out of your terrain fileset, using one of the commands documented in its help.doc file.)

f) First compile test

OK, you’ve got your file saved, now the fun begins. First, copy (do not move!) your new tutorial2.pcx file upstream to the mtt2 folder. We will now discover what sort of complaints mtt2 will have with your edit. If it isn’t already open, pop open the command window at the mtt2 folder, and type in the following command:

[whatever_folder_path]\mtt2>mtt2 -d4r tutorial2.pcx -qp

This is called the First Level Compile Test. It does not actually compile your work back into the terrain, it just checks to see how bad things could be messed up if it did. You will see an output that looks more or less like this:

and might continue for quite a few lines – at least 250 for this tile. Don’t worry about the “Warning:” at the top, it always says that. The first thing to do is note the bottom of the printout. If it looks like this:

congratulations – mtt2 managed to get to the end of the file and exit without hanging – your errors aren’t too drastic. But if it looks like this:

with no “C-prompt”, you must try hitting enter, and failing that ctrl-C, to get the prompt to appear. Until you see the prompt, mtt2 is still running, flailing away in confusion somewhere in the depths of your machine.

Whether or not you got the C-prompt first time out, you are bound to have gotten some errors, so the next step is to scroll back through your huge scrollback buffer to see what they are. For instance, I’ve contrived to give myself an error in the midst of the printout:

(you’ll note that mtt2 has a cockney accent). What this is saying is that there is something wrong at or near the locations 1536, 2810 and 1517, 2814 . These are usually, but not always, two points (white dots) on a line, and the error is in between them. In this case, though, as I have been doing this for quite a while, I recognize that 1536 is a multiple of 256 (I’ve been doing this so long I can count to 8192 in 256s), and a “Polygon wiv RouteCol” means mtt2 is pretty sure that a location near a white dot is a line (route) colour pixel where it shouldn’t be. It suggests it should be a Polygon (fill/land-use) colour, but usually it really means a white dot isn’t correctly placed relative to the line. When the location is a multiple of 256, that means we’re on a tile border, and the error really is that a line has gone across the border without having a dot at the crossing point, which is the error I intended to create.

When you get an error like this, you must open your edited file again ( !! the one in the project subfolder, not the copy in the mtt2 folder), and use your editor’s pixel coordinate display to locate the region of the image which mtt2 is complaining about, figure out the problem, and adjust it as you think is required to correct it. If you get a lot of errors (usually of the “lost my way” variety), go through and fix them all, as best you can. Note, though, that mtt2 will often encounter the same error many times, as it crawls along several different lines which lead to the error. You can usually spot this as it will announce a series of errors whose reference locations are all within about 25 pixels of each other, and when you go there you will find the locations are all at points along three or four lines which intersect in the centre of the region. Somewhere near the centre you should find the error. For this trial, we’re doing a pretty simple edit so you shouldn’t get many errors, just remember if mtt2 fails to terminate (no C-prompt), then you probably have an island which isn’t linked back to a tile boundary. I’ve already discussed the most common errors, and you aren’t likely to get any obscure ones, but you can check the appendix, for some help on some others, and also check the tips and hints in section 7. I haven’t been as diligent as I should in collecting examples of errors and their fixes for this tutorial, as I’m usually completely consumed with squashing the bugs and getting the project finished…

When you’ve done your best guess at fixing the errors, you must save the file again (as tutorial3.pcx this time), in the project subfolder, and don’t forget to copy it up to the mtt2 folder, then run the first level compile test again, on the new pcx, and see how well you’ve done. At the beginning, you will probably find you get errors again, and it may take four or five tries till you’ve got it happy (or more – if you’re stuck, just pop by the A2A BoB2 General forum and ask for help, and I’ll get you sorted… I just realized I haven’t identified myself anywhere in the body of the tutorial through all the previous versions, maybe that’s why I never hear from anyone! I am “PV” on the A2A forum, and “PV1” at SimHQ, where there was a PV before me). While you are working, keep the command window open so you can scroll through and refer to it. When you’ve got a new pcx to try, you can save some typing time by using the “command recall” function of the DOS environment – your UP arrow key should display the last command you typed, and you can just edit the filename to the new version number. This function is even handier with the subsequent mtt2 commands where the parameter strings get a lot longer, and typing them out is a bit of a pain (especially as I can never remember them and have to always look them up).

Your edited pcx file is free of errors (at the first compile test level) when the mtt2 output for the compile test has only lines of the form “xx edge points defined. xxx total points defined. Compressed to xxx bytes intermediate storage” and ends with the command prompt appearing. When you’ve scrolled carefully through the output and determined that that is indeed the case, then congratulations, you’ve made it through the First Level Compile Test, and it’s time to move on to the Second Level Compile Test.

g) Second compile test

The procedure for the second level compile test is similar to that for the first level test, with a few important differences. First, the command parameters are a bit more elaborate, and involve creating a new file:

[whatever_folder_path]\mtt2>mtt2 -d4r tutorial4.pcx -qp -qu -quo -w tutorial4test.pcx -qp

This command first repeats the process of the first command, creating a test packing of the data in the pcx file. Then it unpacks that data, and attempts to write a new pcx of it. This test will hopefully prevent the insertion of data into the terrain which cannot be subsequently extracted. In NER’s original tutorial, he had the second file written directly over the first, by giving them the same name (all his files are called work.pcx, which strikes me as a singularly bad idea). I insist that for this test, the second file have its own name, formed by adding “test” to the input pcx filename. After the second file is written, the last parameters -qp repeat the first level test on the new file. As a result, your mtt2 text output will be in three sections. The first section should look just like the output for your successful first level test of the input pcx file, lots of lines of “points defined” and “intermediate storage”. Then there will be a section where mtt2 tries to unpack the data and construct the second file, and it will have its own error messages. Dire errors may cause the program to hang here, or it may announce that it can’t build the new file, because of errors it has found – it is pickier about things this time around – or it may build the new file, but still have some complaints. In the best case, it will simply inform you that it has successfully built the new file, and written it to disc. Then the third section will be another section like the first, a first level compile test, but this time run on the file mtt2 has built.

Because mtt2 is not terribly bright, it may have made some terribly silly mistakes when building the second file, and you will have to troubleshoot them as you did in the first level compile, reading through the third section of the text output. However, in this case, you will want to have your original file (in the project subfolder) open in your editor, and you want to have the tutorialxtest.pcx file up in the mtt2 folder open in something (I usually use IrfanView, so I don’t get mixed up and start editing the wrong file…) to help you see the problems. This is where you get to see how stupid mtt2 is (well, maybe not with this first simple edit, but with more ambitious projects, you will see), as it reworks the lines you have drawn. A typical error is where you have drawn two roughly parallel lines quite close together, but with a few pixels in between, so there should be no problem. But when mtt2 regenerates the pcx, it chooses different directions for the lines as they leave the white dots. For instance instead of a simple straight diagonal line from one dot to another one lower and to the right, it will often draw a line leaving the first dot on the horizontal, then curve down in a sharper diagonal and curve back to horizontal to join the second dot. This s-shaped curve now sticks out such that a second line beside it will bump into it, whereas if both had been drawn using the obvious corner pixels and direction for the diagonal line, there would have been plenty of space for them. This will generate the expected error. To fix this, you have to increase the spacing beween the lines, or try to arrange them such that the curves that mtt2 makes bend at the same locations on each, and thus accomodate each other. The latter is quite difficult and generally not worth the trouble.

At any rate, the nice thing about this compile test is that as long as mtt2 has managed to get as far as writing the second file, you can pretty much see the errors that it is making, as you have your good input pcx, and the coordinate locations from the mtt2 text output, to help you locate them. Your problem then becomes guessing how to make your input pcx so idiotproof that mtt2 can process it without screwing up. Generally this will require a few iterations, as with the first compile test. Do some edits, save with a new suffix number, copy to the mtt2 folder, run the same test again, and see how things have proceeded. Again, for this simple edit you shouldn’t have much trouble.

When you have succeeded in editing your pcx into a form that mtt2 cannot ruin, you will have a second level compile test output which has simply two sections of text full of “points defined” and “intermediate storage”, bracketing a middle section which looks something like this:

and it will end with something like “time in mtt2 2 seconds” followed by the command prompt. When you have scrolled through and convinced yourself that this is indeed the case, and you have no more errors, then it is time to move on to the next step, actually inserting the edit into the terrain.

h) Inserting your edit into the terrain

Up to this point, the six terrain files in your mtt2 folder have been read from, but have not been altered. The following command will update those files with the edit we have now prepared. Again, it is imperative that there are no errors in the pcx you are inserting (ie, your file has passed the second level compile test, with dialog level set to -d4 or larger, with absolutely no complaints), otherwise the terrain files may become broken in ways which make them pretty much impossible to fix. They may look OK, but you suddenly find you can’t extract a region for further editing. If this happens, you must go back to a previous good fileset, and you really don’t want to discover the problem after you’ve entered several edits past the bad one, as they will all have to be discarded. You may be able to re enter them, if you’ve kept a full archive of your projects, but really, the best thing is not to have the problem in the first place. At any rate, here is the command format:

[whatever_folder_path]\mtt2>mtt2 -d4r tutorial1.tga -r tutorial5.pcx -qbw 185 216

This command calls up the original heightmap file tutorial1.tga, which we haven’t touched, but is required for the compile; and it uses the final successful version of the pcx file, which here is apparently version 5. As with the tests, mtt2 is using the files in its own folder. The numbers on the end are [StartX] [StartY], the lower valued coordinates of the block we have edited. You have saved those numbers in a text file, so you refer to the text file to retrieve them. For this command, the .tga file must come first. When this command is run, as you are using a good pcx file, you should see no error messages or other complaints, and mtt2 will exit to the command prompt. And you will find that the six terrain files in the mtt2 folder now show the current date under the “modified” column, and some of them may have changed very slightly in size.

OK, now we want to view our result, so, of the six terrain files, we need to copy the two .grd files back into the /GridData folder of your BoB2 install, overwriting the two files there, and similarly, copy the two .ind files and two .dat files back into the /landscap folder, overwriting the four files there. Once the files are in place, you can fire up BoB2 and fly or alt-V yourself to the edited location (fortunately, it’s right beside the default take-off, so that’s not hard). When NER did this with the original BoB-1 terrain in 2002 (or so), the result looked like this:

Your result will have different terrain textures, and will look a bit crisper as the textures are higher res, but the overall result should be similar.

Finally, as you have successfully completed your edit, and you have a full record of all your files in the mtt2/tutorial/ folder, you can delete all the versions of the pcx file from the mtt2 folder, to clear that folder for the next project.

OK, that is the first introduction to terrain editing, all done. You should now have a fair idea of the basics of land-use editing. If you actually followed along, you will want to now overwrite your edited terrain fileset (the six master files in the BoB2 landscap and gridData folders) with the originals you are keeping in the subfolder of your mtt2 work folder, as I don’t imagine you want to keep that edit.


7) A compendium of notes about the editing process, being a summary of many useful bits of information we have gleaned:

Having gotten through the basic land-use editing tutorial, it’s time to dig in to the details of the specifics of the terrain types. You can regard this section as a sort of general reference. I guess we should put the palette map up again:

The Fill colour patches along the top row of the map have index numbers 0 to 19, and are associated with the texture files img0000 to img0019, from left to right. Sea and Lake get img0020 and 21 (used in BoB2 only when Water Detail is set to Low), then img0022 to 26 are the left column of the Populated Areas section, top down. Of the remaining img files, they are associated with the Specials as follows: 27 – city base, 28 – sand, 29 – chalk (not used for cliffs, that’s a different one), and 30 – runway. 31 is an oddball and somehow never managed to make its way on to the original palette map, but I have added it, and its rotations, in the latest version of this map. It is now assigned a distinctly French farm texture, and so ought to go with the other colours along the top row, but I’ve squeezed it in where I could fit it. All 32 img00xx files have colour index numbers corresponding to the numbering on their filenames.

Note the word “rotate>”. This is associated with the Fill colours except for the Specials. It indicates that the four colours along the direction of the tailless arrow will all use the same texture image, but the image will have a different orientation with each step. For some obscure reason, Rowan arranged that the texture image files as viewed in the landmap2 folder are mirrored when invoked via the top row of colours on the palette map (and the left column for the housing textures). The mirrored texture is then rotated right, and left, respectively, for the second and third rows. The fourth row uses the texture unmirrored as it appears in the folder file. As all four colours for each texture type were used with about equal frequency by the Rowan artists, this means that the textures appear in mirrored form about 3/4 of the time. This is useful to know if you have decided to alter a texture file, and are trying to locate your change on the terrain.

The Specials do not have rotations, as the textures are not sufficiently distinguished that rotating them would yield a different appearance.

The four fill types (grass, fields etc) across the top of the palette map (plus the four “31” fills) behave the same, with the exception of the one column labelled WOOD. They also function similarly to the Populated Area fills, however the latter are placed on the terrain at one half the magnification, thereby giving a higher level of detail to built up areas. The WOOD column invokes img0015, tree tops. The texture image is placed and subject to rotations as described for the other fills. In earlier versions of BoB and BoB2, this column was subject to a further modification when the BoB “Raises On” graphics option was selected. In that case, the regions of this texture were lifted about 6 metres (18 feet ) upwards as a block, a rather low tech way of representing a block of forest. This was the subject of much criticism, and was finally eliminated around patch v2.09 or so.. At any rate, the blocks had sides, and those should show trees on them when the raise was enabled. This was achieved by outlining these regions with the colour “trees”. This produced the same string of trees as the two hedgerow outlines, but while the hedgerows always appear, the “trees” outline only drew its trees when the raises were enabled. Now, the renderer has been reworked so that individual tree objects (sort of 3D – they are two copies of a tree image passing through each other at right angles, but they look 3D from most angles at distances beyond about 100ft.) are placed at intervals along the edge of the forest texture regions, as well as scattered through the .interior of the region. The frequency of these trees is controlled by two bdg.txt variables.

OK, that about covers the Fills, now the Outlines: “Fake” (index #153), I have already discussed, and I’ll have much more to say about it when we discuss heightmapping. The “cliff” colour is an outline colour which is to be drawn parallel to the shoreline, and causes terrain height on the seaward side to drop to zero, and chalk cliff face texture to be placed on the steep surface created. Obviously, this could have potentially dire results if this colour is used far from the seacoast. Also, do not use cliff as a shoreline, or you will create strange anomalies in the rendering. always run a strip of beach sand, however thin, between the cliff line and the ocean.

The “coast” colour was to be drawn bordering Sea or Lake, and in BoB1 it caused the animation of breaking waves on the water texture. It was not required, however, and when not used (usually replaced by fake) it would give the impression that the water was disappearing under the shore, as if the shore was a dock on pilings. With the advent of BoB2 DX9 water, this function was lost (maybe it still works with Low Water Detail?) but we may develop a way of bringing back breaking waves in future, so it is best to continue to use it as Rowan did, wherever waves would be breaking on the beach.

Currently, all the various river and stream outlines result in the same thin stream line on the terrain. It is fetched from the file \IMGMAP16\, and is the strip of stream-looking terrain near the top of the image. On the terrain it renders as perhaps 3 metres wide. If you want to create a wider river, you can draw it explicitly using a region of Sea or Lake fill down to a width of 10 metres (2 pixels). With Sea and Lake, the DX9 water will glint, reflecting the sky, whereas the blendmap image is just another strip of colour on the terrain. While you have the blendmap image open, you can browse through it to see the other items which are used by various Outlines: an equal distance further down from the top of the file is the texture strip used originally for Minor Rail . Up to about patch v2.08, the other rail colour, Major Rail, created a brutally ugly featureless solid ribbon of green-brown colour, which was not accessible as a texture anywhere, but rather was generated by the renderer. This has now been eliminated, so Major and Minor Rail lines now both use the blendmap rail texture.

Other strips on the blendmap image provide the texture for B Road, Minor Road, and Footpath (not sure about A road), as well shoreline for Coast, and as the ground under Hedgerows (both Thick and Thin, which seem to be treated equivalently in all aspects). The hedgerows also currently result in the generation of “billboard” two dimensional strips of trees. These are fetched from the file \MaskMap\ (or it may be treeline.pcx and treeline_trans.pcx – the second file is an “alpha-layer” file, providing transparency data. Texture images which require transparency, such as a tree which has a surface of leaves with empty space between, are handled by one dds file, which can incorporate a separate alpha layer, but require two pcx files, one for the image and one for the transparency map. The BoB2 renderer knows if a particular image is supposed to have an alpha layer, and if it can’t find a dds file, it will look next for a pair of pcx files, one of which must be named …_trans.pcx.).

The outline called “Roadway” (index #161) turns out not to be usable. mtt2 uses it when it creates “widened” routes via a command line parameter “-e” which is tacked on to compile commands. The widened routes are ghastly, like Major Rail, so we don’t use them. But at any rate, when -e is used, mtt2 inserts the roadway colour into the pcx in fat strips along roads before passing it to the renderer, and then strips it out before building a pcx from extracted data, so the user never gets to see it under normal circumstances – if you try to use it, you will just get an error. I discovered it when mtt2 crashed on second level compile with -e set on, and the partly finished …test.pcx was left in the folder with the fattened routes still showing. I put it on the palette map before I discovered it would be rejected if I used it by hand.

Other notes:

* As your image editor can also show you index numbers, you should get in the habit of checking those, rather than relying on the appearance of the colour – some of the 256 colours are so close to each other in appearance, particularly the dark green and red-brown ones, that under even ideal lighting conditions, it is almost impossible to tell them apart. Here is a map of the colours in our palette file, the one used in all BoB terrain pcx files, and in the BoBPal1.pcx land use palette map image, (and stored in the pal.pal file in your mtt2 folder). It has been aligned here to show the logical structure, as usual for computer stuff the structure is based on powers of 2, here 2^5=32:

You can see how difficult it is to distinguish some of the colours on the upper left to lower right diagonal, but each one (among those numbered) is distinct (they are also the first in order from the start of the palette to use that colour; 31 is black, as are several unnumbered later slots, starting with 52, but 31 is the first to use black, and no numbered slot after that is black). Of the 256 colours in the palette, those which are known to have a function and be used in the terrain pcx files have their index numbers written. There are 130 of them. Binary usage suggests it ought to be 128, so I’m not sure what is going on, but #132 and 161 are somewhat suspicious.

For the most part, it is easy to see the relationship of the colours here to the colours on the BoBPal1.pcx palette map. I’ve already described the first 110 (which takes us to index number 127). The roads are 128 – 131; 134,135 are Major, Minor Rail; 140..143 are Major River…Stream; 146 is Trees; 148 Coast; 149 Cliff; 150,151 Hedgerow Thick, Thin; 153 Fake. 132 remains somewhat of a mystery, I’m afraid. It has been found on the terrain where it variously seemed to be coding for hedgerow, or footpath. If encountered, it is best to determine what it seemed to be coding for, and use the explicit colour instead. Obviously don’t use it for new work, it could cause trouble.

* You cannot get too enthusiastic with creating terrain detail. mtt2 will complain if it finds it is generating more than 500 polygons in a single 1.4×1.4km tile. I do not know how it counts (chooses to build) the polygons, but one would expect that this has a fairly simple relationship to the number of white dots in the tile. If you get this error, you will have to go into your tile and straighten lines to get rid of some white dots. There is also a “too many points” error, which is invoked at the point of 250 white dots (counting the four corner dots) in a single tile. Obviously, the same remedy is required.

* For road placement errors, one thing that seemed to work for me when an intersection of similar roads kept throwing up errors (the most common type of problem – mtt2 keeps counting five road directions out of the intersection when there are clearly only four), was to change one of the roads to a different type. This seemed to help mtt2 sort out which roads were which, and get it to count to four properly.

Now let’s look at some useful techniques for doing more elaborate work well…


8) Using a Stack

a) How to build a stack

In order to do good, accurate period editing, it is best to have all your map resources available right on the image you are editing, adjusted to the correct scale. Fortunately, image editors include this feature, which is called stacking. Stacking also will be indispensible when you come to height editing, where you want to edit the height .tga file at points corresponding to features on the pcx file.

Here is a pic of a two layer image being edited in gimp, the .pcx file image overlain by a semi-transparent topo map:

Here is an example of the file I used when creating Calais. All these views are of the same location on the image, but with different layers in the stack turned on:

The different layers can be set to different brightness and transparency, and moved up and down the stack. In the last image, you can see the land use pcx showing. Editing is active on one layer only, so I can edit the shapes on the pcx layer while being guided by the maps and aerial photos on the other layers – it is just like tracing. How to access and use stacking varies by image editor. Before I explain how to do this with gimp, as an example, I must first clarify some terms I will use. Indexed colour images, I think, have been explained pretty thoroughly already. The other types of images you will need to know about are greyscale – where only shades of grey are used, often a special case of indexed colour, with 256 shades of grey; and RGB, which for our purposes means 256 allowed values for each of the red, green and blue components of each pixel. This is also known as “8 bit colour” or more commonly “24 bit colour”(8+8+8). The palette for an RGB image is always the same, 256*256*256=16,777,216 colours, so there is no palette file for such an image.

For gimp, there is always an active layer. If you haven’t set otherwise, the image is only one layer, which is active. Opening the Layers dialog (main gimp window >file >dialogs >layers) and selecting the New icon creates a new layer, which becomes the active layer (indicated by a highlight bar in the dialog). You can then drag and drop an image icon from the Layers dialog of another gimp image window onto your working image, and it will be placed on the new active layer, and you have just created a two layer stack; but be sure before you do that the image “mode” (greyscale, indexed, or RGB) is compatible with the layer already present in the image, or gimp will crash. The rule is, the new layer can’t have more or different colours than the existing layer. Thus, if the working image is RGB, you can add any other mode; but you can’t add an RGB layer to an indexed layer, nor can you combine two indexed layers with different palettes. However, this is usually what you want to do – to add RGB or grayscale map or recon photo image layers on top of an indexed pcx land use layer. (In gimp, you also need the layers to be RGB in order for them to be able to be made transparent, so you can see through to the other layers you want to align with, and the pcx layer you want to edit.) In order to do this, you must first open the pcx file in gimp, and go to the Image>Mode menu item, and select RGB, to convert the image to RGB. Then you can add other layers as described above.

The next step is to align and stretch the various layers to match the size of the pcx layer. This is best accomplished with a pencil and paper, a calculator, and the image editor’s measure tool. You should be able to measure the angle and distance in pixels between any two points on an image. You will usually be measuring against the pcx layer, at least to start. If you have a good detailed map or aerial photo that covers your entire work region, it is handy to first align and scale that layer against the pcx layer, then use it to align and scale all other layers. This is because aligning and scaling requires lots of details which can be used as measurement landmarks, and the original pcx files are generally pretty sparse for such features. Larger edit regions increase the number of available landscape features on the pcx image, and so are easier to get an accurate scaling with. In some cases it may be necessary to start with a much larger map region than you intend to edit, in order to find sufficient landmarks of whose location on the pcx file you are confident. After scaling your main reference map or photo to this extended pcx layer, you can crop the image down to the area you wish to edit (no point in keeping the larger area, as it increases the computer workload in the image editor, and also gives more opportunities for problems with the mtt2 compile). Anyway, the process for aligning and scaling is to locate a pair of landscape points in each of the east-west and north-south directions, which appear on both the layers you wish to align, and are as far apart on the image as possible. Now measure the separation and angle of each pair on both layers, which gives you four sets of numbers, each one a distance in pixels and an angle in degrees.

I guess I’d better provide an example. Here are two layers, one is the pcx layer for my Purbeck work, and the other is a composite of British aerial survey images on a section of NPE map. I need to adjust the composite to match the pcx, so I choose the most obvious widely separated landmark pairs I can see on both images, and measure the pixel distance and angle on each image for the north-south pair A, and the east west pair B. For the Aerial/NPE image

I get A1 is 1825 pixels at 84 degrees (where 90 degrees is due north); B1 is 1884 pixels at 14.25 degrees.
On the pcx image,

I get A2 is 2584 pixels at 84 degrees; B2 is 2656 pixels at 14.5 degrees. First of all, the similar angle values indicate that both maps are using the same orientation, so I know I won’t have to rotate the NPE map to fit. Now I check the distance ratios: A2/A1 => 2584/1825=1.4159; B2/B1 => 2656/1884= 1.4098, so the north-south and east-west distances are very close to the same scale (the original Rowan landscape is a bit crude, so it is reasonable to assume the discrepancy is due to this, and treat the NPE map as having a uniform scale in both axes) so we won’t have to scale our NPE map separately in its two axes. We just have to give it an overall resizing up by about 1.413 (split the difference), with no rotation, and it should land over the pcx map nicely. This is not always the case. Different maps are drawn with different orientations and projections, and you may find you need to scale the north-south and east-west axes by different amounts, and rotate the map’s orientation. This is especially true with aerial photographs. Photographs taken obliquely may require a “perspective” adjustment (aka “keystone” correction) to correct for features shrinking into the distance. Fortunately this is also a typical feature of image editor programs.

In order to save the multilayer file you have created, you must save it in gimp’s native file format .xcf . I assume the process works very similarly for other image editors.

b) managing the pcx layer on a stack

As the pcx layer is now RGB, as far as the editor is concerned, all colours are allowed, so it is up to you to ensure that you only use the exact RGB values of the allowed colours of the BoB palette. The easiest way to do this is to have the BoBPal1.pcx file open while you edit, so if you need a colour, you can lift it from there with the eyedrop tool. You must also ensure that you don’t switch active layers, as this can lead to many undesired results, such as drawing your edits on the wrong layer, or picking up a colour from another layer and dropping it onto the pcx – as maps are mostly white, you can easily pick up an off-white and start using it for your white dots; this is a miserable pain to fix, dot by dot…

Now comes a rather important issue which can be a bit confusing, so I’ll try to explain it clearly. The details will necessarily vary according to image editor. On your stack, you now have a land use image which you’ve converted to RGB, and which you will be editing by tracing desired features from other layers of the stack. When you are done editing, you are going to have to convert this layer back to “indexed” in order to extract and save it as a pcx. This is a critical step, as the index assignment of colours must be perfectly regenerated as it was in the original pcx, in order for mtt2 to interpret it correctly, while your image editor will much rather generate a new index. In order to reproduce the original index, you will have to have a copy of that index (a palette file), for the editor to build from. Thus, you must locate the function in your editor which will extract and save a palette file from an image In gimp, this is quite a journey: you must have the image whose palette you want to extract and save (best is BoBPal1.pcx) open and active. On the image menu bar, select Dialogs>Palettes, and at the top of the Palettes window is a bar with the word Palettes, and a (tailless) arrow, and an X. Left-click the arrow, revealing a menu; select Palette Menu>Import palette>Image, and select the image and give the palette a name (ie BoBPal1) and click Import. Now the BoBPal1 palette will be saved in gimp palette format, as a file in the gimp program palettes subfolder, and it will appear as a selection on the gimp Palettes menu.

With the correct palette now available as a selectable option, you can go through the process of extracting the land use layer of your stack file as a pcx file. The best way to do this is first to highlight the pcx layer of your stack in the layers dialog window, and set it to fully opaque using the slider at the top of the window, and then drag and drop the layer icon onto the main gimp window. This will cause gimp to create a new image of that layer. At this point it will still be RGB. Then on the menu bar of this new image, select Image>Mode>Indexed, and you will see the colour indexing dialog window come up. Say no to Generate Optimum Palette?, rather select Custom Palette, and uncheck Remove Unused Colours? Now click on the coloured block directly below the words Custom Palette, which will open a palette selection menu. Locate and select the BoBPal1 palette there that you have saved. Finally, select No colour dithering, and you’re good to go. Hit OK and the image will be converted correctly back into indexed form. Then you can select Save As, give it a new name (add a number suffix to its original name) with a .pcx extension, and save it. Whew. OK. Once you have the new pcx file, you get to go through all the compile test tweaks and repairs as described in the basic editing tutorial back in section 6. And a large pcx fresh from a stack will invariably have lots of errors to fix – they may get fewer as you get better, but they’ll never go away.

If you do run into trouble, pop in to one of the BoB / BoBII fora, and someone will probably be along to help. Hopefully, with the help of this doc, as time goes on the number of folk with the necessary knowledge should grow, but for now there may be only two or three of us who can help, so be patient, it may take a day or two to get back to you.


9) Fartiles.bin

The Fartiles.bin file contains data for generating the view into the distance, in BoB2, at a lower resolution than the near tiles. This allows a view for many miles without the renderer having to chew through a lot of computation – basically the distant terrain is pre-constructed and stored in the file. This file is 256MB, and resides in the Landscap folder. If you do a significant edit to the terrain, changing the shape of shorelines, or reassigning texture locations, your new terrain will not coincide with the data in the existing fartiles.bin file. This means that when flying over the terrain, you will see a moving seam where the freshly computed terrain incorporating your edits meets the old terrain data expanded from the existing fartiles.bin file.

Fortunately, the capability to build a new fartiles.bin file is incorporated into the BoB2 exe. All that is required is to open and run the 3D world of the sim, with a few adjustments. And, fortunately, the file will compress to about 25MB, which is still quite large, but much more tractable than 256MB. When combined with the six terrain files, the total compressed size is only around 50MB, which is not a large download these days, so this makes a reasonable release package.

To generate a new fartiles.bin, first, back up your current file if you have a need to – the process will overwrite it in its location in the /Landscap subfolder of your install. Next, you need to create a new BoB2 launch icon – right click on the current icon, and select “Create Shortcut”. Find the new icon on the desktop, right click on it, and select Properties. Now select General, and rename the new shortcut to something like “FarTiles Generator”. Now select Shortcut, and in the Target field, after the current entry, add a space, and text such that the result is exactly (assuming you use the default folder location)

“C:\Program Files\Battle of Britain II\BoB.exe” -SAVETILES

Capitals and quotation marks are all required as shown. Click OK to save the new shortcut.

Now ensure that all your edits are installed, and your terrain appears in-game as you wish it to, using the current standard BoB2 release texture set available from tha A2A BoB2 forum (unless you are planning to provide your own texture set to match your unique fartiles file). As the data in the fartiles.bin file captures the appearance of the terrain on the computer where it is generated, it retains the textures used on that install, so in order to match with the near terrain on other users’ installs, you want to use the common standard texture set.

Now, when you are ready to run the program to save a new fartiles, first shut down all other programs and activities. The file generation process is quite resource intensive, and it needs all the computing power it can get. It is also vulnerable to interruptions, which can corrupt the file, so it is best to disconnect from the net, and shut down any apps that might try to throw up an alert window, or otherwise pull cpu focus from the BoB2 program. Also, disable multiskin in bdg.txt if you use it, and while you are in bdg.txt, set GAME_PAUSE=ON, which will cause the 3D to start in paused mode. This is probably a good idea, as you aren’t trying to actually run the 3D – once you get to that point, you’re done. Now, launch BoB2 via the new shortcut. Select the default takeoff IA mission, with sunny afternoon parameter setting (the least file loading required). Once the 3D screen is launched, the computer will sit and think with a lot of disc accesses, for between ten and twenty five minutes, depending on your machine. You can wander away while you wait for it to finish. Eventually, the machine will get to displaying the 3D screen. It may crash to desktop at this point, or more likely it will just show the initial cockpit view. Just alt-x out and close the program in the normal manner Now check the /Landscap folder, and the fartiles.bin file there should show 262,144kB, and Date Modified will be today’s date. You’ve done it. It is recommended to do a scan of the terrain to make sure the file wrote without corruption – zip around in alt-V mode, paying particular attention to coastlines, and watch out for stray tiles out in the ocean. Sometimes fartile generation fails for unknown reasons, and if so, you just have to run the process again.


10) Terrain Height Editing

a) Simple height editing

You may have noted that it was mentioned in passing that in the file extraction process for terrain region editing, a .tga (targa) file is extracted which encodes the height information. This file must be used when repacking the edited terrain .pcx back into the terrain data files. It is possible, however, to edit this file before repacking, thus changing the height data of the terrain. (Gimp users, look here for an outline of the workaround for gimp’s heightmap file limitations.) If you open these targa files in an image editor, they look rather like this:

The colour coding used is a ramp of red value from 0 to 255, with green and blue both zero, followed by red dropping back to zero and green incrementing to 1, red ramps again til at 255 green goes to 2, and continue. It is a simple counting system, with each least significant (red) bit representing 4cm altitude. RGB=0,0,0 is sea level. Using a count in base 255 gives a HUGE dynamic range, so by the time the blue bits are invoked, you are into the alpine heights, and if blue becomes bright enough to see you are right out of the atmosphere. But how does the editing work? The pic above is of a section of the French coastline at Wissant, and it shows the result of an experiment to insert a sandbar just offshore. I had drawn a simple rectangular shape, and this is how it looked after it was loaded back into the terrain and then re-extracted. This should give you some sort of an idea of the complexity of the process. Basically, mtt2 will smoothly vary height between points, to create “facets” – triangular surfaces anchored by corner points, and the points that it uses are the white dots of the terrain map pcx. You can put whatever colour you want on the targa, unless it corresponds to the location of a white dot, and mtt2 will ignore it (well, more or less – there seems, from further investigation, to be some effect, but I haven’t figured out the details).  Looking at the targa, you should be able to tell where the white dots were in the accompanying pcx. Here is another pic, from a gimp editing session, with a stack of layers including the .pcx, the targa, and the reference topo map I was taking data from:

At this size, you can see the white dots which mark out the tile grid every 256 pixels, and also mark out every line change in the terrain map. And you can see how the contours of the targa relate to the dots. The relation is not simple, however. I initially thought that I could create a targa from scratch to go with a pcx by simply computing the colour code required for the position on the targa over each white dot, while leaving the rest of the .tga file blank, and that would be enough (regardless of the content of the .pcx file), but I found that there is some sort of odd order to how mtt2 decides to choose the way it builds polygon planes among the dots. There is not just one solution, and while I thought that mtt2 would make what I would regard as the simplest solution by making triangular surfaces of each three nearest neighbour dots, in fact it will often create a long thin “spike”, a triangle which reaches between nearby dots to link with a distant dot, so that what I expected would be a simple smooth mound gets divided by a deep ravine down the middle. I have not yet figured out what all the rules are, but it does seem that the tile corner dots get some priority, and triangles seem to be generated by a scan around the image from those points like a ray sweeping out clockwise, which will link together each sequential pair of dots encountered around the sweep into subsequent triangles (along with the origin point), regardless of their distance (within a single tile). To prevent this process from creating ravines in my hills, I first used the blue “fake” colour to draw a line out to a point which is in line with a side of the spike, essentially occluding the distant point from the “viewpoint” of the tile corner dot, then setting the height colour I want for that new, nearer dot. It has since become evident that drawing a blue fake line across the offending spike is all that is required, as mtt2 will not usually (there may be exceptions) run a terrain facet through a fake line. Rather, the line seems to always form one edge of a facet.

Here is a series of images showing how I added some small hills above Folkestone, based on an aerial pic I was provided (I didn’t have hi-res topo maps of Britain, as most of my attention had been on France). The first pair are the region as extracted from the BoB terrain:

 Now I add the “fake” blue lines to put white dots along the hill tops, colour the corresponding targa with the height (computed colour) I want at each of those dots, and use mtt2 to insert the result into the terrain (the syntax is the same as for replacing edited pcx files, as a targa file is always referenced). The targa below right is what I saw after re-extracting the data:

The left hand hill is not as I expected – the north slope is far too steep, so I will edit more to define the slope better. I tried once with two extra points, and got a ravine and a third hill, but I didn’t save any images from that trial. The .pcx below has four extra dots, and you can see height colour points added to the targa on the right – there are four, but only two show up well (if you zoom into the image – they are only one pixel each). This is the input targa, before being read in to the terrain:

And here is the resulting targa, and thus height contour, after the above files are inserted into the terrain by mtt2, and the targa is re-extracted:

The ravine has been eliminated, and the final north slope is suitably modest.

This got the job done, and it’s perfectly viable for small edits over a few points, but it’s far too labour intensive to consider for large regions. Since I wrote that, we have made great progress, learning much more about what is possible and how best to make mtt2 behave to yield the desired results. One of the major developments is that we have located freely downloadable satellite “SRTM” height data, and have learned how to insert it into the terrain. You can read about that in the next section. Another major advance is that we have determined that mtt2 respects blue “fake” lines as having some height-defining authority. It will not creat a polygon “spike” through a fake line, and will always try to vary the height smoothly between dots along a fake line string. (The fake lines are used to outline airfields to ensure that they are flat, so this sort of makes sense.) Thus, you can stop a spike by drawing a fake line across it, and most importantly, to encourage desired hill shapes, you can draw a few height contours (or as small a set of segments as needed) in fake line, linked to constant height contours on the red heightmap, and you will get terrain with sensibly generated height according to the contours you have drawn. Furthermore, mtt2 seems to have some understanding of how streams are supposed to work, so if you are drawing hills which have ridges divided by ravines with streams in them, you can get good results fairly quickly by drawing along the peaks of the ridges with fake lines, then drawing the streams down the bottom of the ravines. Paint the red heightmap with the appropriate heights following the fake line dots and the stream dots, and the overall shape should get compiled pretty much as you intend.

Here is an example from my work with Purbeck, showing all the latest advances in use. These are two views of the same location on the working stack, first showing the contours prepared in fake-work:

and next the same region with the heightmap layer turned on around 80%:

The rectangles in the second image are regions of constant height value as provided by the SRTM data. These are roughly 56m east-west by 90m north-south, or 10×16 pcx pixels. This is too low a resolution to make a decent shoreline, or satisfactory steep hillsides (you are liable to get sawtooth edges), so you can see where I’ve gone back in by hand and adjusted the heights tracing along the contours defined by the fake lines, and along the cliff edge at the shore, to ensure an accurate rendering. To make this process even easier, I have included with the tutorial package a file HeightMetreColours.png, which provides the correct colours for the Rowan heightmapping system for the first 210 one metre steps from sea level (the system actually steps in 4cm increments, but one metre is plenty for most applications). You can just put up this image and pick the required height colours from it with your editor’s colour picker tool.

Here is the map layer of the working stack, 67% visible above the other two layers, showing the Ordnance Survey topo map I used to trace the contours needed to detail the height:

All this doesn’t guarantee mtt2 will put your height mod together the way you want. Here are three pics of this region at earlier points during the process. I would make the edits, then go look at the result, and go back and tweak it again until I finally got rid of all the silly accordion folds and got a nice smooth hillside:

One persistent error was due to a single pixel which was off by one integer in green value, so it looked identical to those around it, but was mapping at 10 m lower. I eventually found it by checking the values of the single pixels over white dots in the region using the eyedropper tool and its digital RGB value readout.

b) Height editing with SRTM data

NOTE: SRTM data has recently (2010 or so) been superseded by “ASTER” data, a new version with 30m grid data for all regions covered, which is pretty much anywhere you might be interested in. The process for handling this is a bit different from SRTM, and the latest mtt2 has been tweaked to manipulate it a little bit. ASTER data can be found at , and it requires creating an account with the NASA data server, but otherwise it is a similar system to the SRTM-DEM process described below, but with the odd difference here and there. I haven’t sorted out a full description of fetching ASTER data yet, but I’ve done it a couple of times, and mostly managed to flail my way through fairly painlessly. I will be doing some more at some point in the future, whereupon I will see if I can make time to write it up. Otherwise, catch up with me at the A2A BoB2 forum, and I’ll try to remember how it’s done and steer you through any sticky bits. Anyway, here’s how to use the SRTM stuff, which I assume is still available.

How to acquire “SRTM” satellite height data, and convert it to a form which can be entered into the Rowan terrain engine (now referred to as part of the A2A “Merlin” flightsim engine).

This method was researched on the web and devised by HurricaneHicken, and allowed him to map the detailed heights of the South Downs onto Kent, greatly improving the appearance of the terrain.

I will summarize the whole process here, as this allows you to retrieve and massage data for any region. (Using this process you could create a whole new terrain for Merlin sims, although implementing it would require tweaking lots of other bits outside of the scope of this tutorial – airfield locations, for instance.) However, as we have done some of this work already, we have available some pre-massaged data files for some selected regions of south coastal England and northeast France. If you think you might find use for this data, enquire at the A2A BoBII forum, and I can email the material – around 3 to 5 MB rar’ed.

OK, now for the process. The first half of this process involves steps which have been worked out by other fine folks out on the net who are interested in flightsimming. We will make a stop at one of their sites now, to retrieve a necessary tool, and learn a bit about what they’ve managed to do. The site is at and there we will pick up the height data manipulation tool “DEM2BSQ.exe” (DEM stands for digital elevation mapping; I didn’t check what BSQ means). This is a brilliant piece of software which does most of the conversions we need, getting the raw data into a graphics format (BMP), from which point we can do some clever graphics-editor-based manipulations to get us the rest of the way.

SRTM stands for Shuttle Radar Topography Mission, and you can learn more about it here: The SRTM data for the BoB region lives at where it is stored in zipped .hgt files, each one degree on a side. Use a map to decide what you want to download (you can use the greatly expandable map from this doc at the website, if you don’t have any other, but it is rather awkward to use, and a paper map is much easier) and select the files by name. Obviously refers to 49 deg north by 1 deg west; the names refer to the location of the SOUTHWEST corner of the tile. Remember that to use these, you will have to assemble them into an image file, so unless you can get what you need from single degree squares, you want your collection to comprise adjoining files, which can be tiled together into a simple rectangular shape. Collect the files you want into a work folder along with the DEM2BSQ.exe file, and unzip all the hgt files.

DEM2BSQ.exe is wonderfully clever and easy to use, with a graphic interface. It knows the lat and long of all the files, so you just ask it to join them, and it puts them right way round. The first step is to convert the hgts to BSQ files, as these are the ones which will be assembled. Fire up DEM2BSQ, and select HGT>>>BSQ, you will be offered a file menu, select the first hgt file and proceed. Before the resulting file is written, you are always offered the option of renaming it. When all the hgt files have BSQ versions, it is time for a little geometry fun. Select “Merge 2 BSQ Cells” (BSQ1 + BSQ2). To assemble a large rectangle, you have to keep track of what you are doing, because the assembly must output a rectangular shape at every stage. So first you ask it to put together two files which are adjacent either in NS or EW directions. From there, you can add on single adjacent files to form long strips, or you can build other pairs, then join them into squares along their long axis. Whatever makes sense to you and is easy to keep track of. DEM2BSQ will always put the files together in the correct positions, but will complain if you are trying to put non-adjacent tiles together.

All the intermediate assembly files are still there, but the new combination files are added to the folder. Continue combining files until you have the full region you need in one image. This file can now be converted to a BMP by the obvious button. So, make the BMP, and you will see that it has a greenscale for height. This is similar to the mtt2 scheme, but the height resolution is only 1 metre per colour step. At 256 metres, the red channel is incremented to 1 bit, etc. Zero height is coloured blue 255. However, there are also usually a bunch of pixels coloured many different shades of yellow. These seem to be at shorelines, and may represent the radar being confused by intereference from reflections off both the water surface and the ground beneath. DEM2BSQ has a tool which will set all these colours to sea-blue, however in many cases it appears that these points should really be dry ground, so you may find it better to use your image editor to set these colours to +1 metre height. At any rate, those yellows must all be removed before the next step.

OK, now you have a final BMP file in greenscale, with blue sea, and with height steps of one metre. How can this be used by mtt2? It can’t, yet. We have to do some more conversions. However, once the conversions are done, because of the way the colour steps relate between the SRTM system and the Rowan system, the resulting file will be pretty much incomprehensible except for its coastlines (as the Rowan heightmap uses black for sea level, which is easy to see). The one metre steps of the SRTM data are rendered as almost completely unrelated shades of red in the Rowan system, so it is usually impossible to figure out what you are looking at, and so fit the heightmap onto a stack or otherwise relate it to the landuse pcx for compiling, unless your edit region has lots of coastline. The best way around this is to fit your SRTM file to size on your editing stack at this stage in the conversion, while the elevation contours are still discernable on the BMP file. For instance, here is an SRTM greenscale BMP file of a region I’m now working on, around Boscombe Down airfield:

And here is that layer, on the stack in gimp, appropriately stretched and slid about till I found how it fit over the pcx:

Now this is the same layer after conversion to the mtt2-compatible redscale palette:

I think you can see that this file is much harder to interpret, and fit to the terrain stack, than the greenscale image above.

OK, so you have your greenscale BMP image, how do you fit it to the pcx? Basically, you do this in a stack, just as you would to fit an aerial photo or topo map to the files.
You will find it must be expanded around 16x in NS, and 10x in EW, to match the size of the BoB terrain files, though these numbers will vary depending where you are on the map. It will also likely require a counterclockwise rotation of between 1 and 2 degrees. The math for this is pretty simple: in latitude, each degree is a constant distance, 90 degrees evenly divided equator to pole. That value is 111km. The SRTM files divide that degree into 1201 pixels, so 92.5m per pixel. The BoB terrain pixels are 5.63m each, so that is 16.4 BoB pixel per SRTM pixel in the N-S direction. However, there will be a bit of error introduced in that value because the data are taken from a vehicle which can’t fly 50 degrees north, so it is acquiring the data at an angle to the vertical. In practice I’ve found the N-S axis multiplier to vary between 15.8 and 16.2 depending on where I am on the map. The E-W axis is more problematical; degrees longitude vary with latitude, from 111km at the equator to 0 at the pole, so the appropriate multiplier varies noticeably from the south to the north of the map. Values in the south of the map where I’ve worked are typically between 10.1 and 10.4, as by 50 degrees north, the spacing has considerably narrowed. This is why the SRTM pixels appear as rectangles on the stack. I can’t explain the need for rotation, it is an empirical observation.

So, now you’ve scaled your greenscale image to fit on your stack. It is an RGB layer.

At this point, if you have a very clever image editor, or you have some clever ideas, you may be able to solve this problem better than I have. It may even be that there is capability hiding in mtt2 to do this, but I haven’t been able to find it. mtt2 seems to be able to manipulate colours only in 8-bit (256 colour) palettes. What we want to do is convert the green 1 metre scale to a red 4cm scale, by selecting the red scale steps at only metre intervals. That is, the first colours in the red scale will be (R,G,B) = (0,0,0); (25,0,0); (50,0,0); (75,0,0); (100,0,0) for heights 0, 1, 2, 3, 4 metres, and continue. At 10 metres, (R,G, B) = (250,0,0) then the red value wraps as green increments, and 11m = (19,1,0), and so on (G=1 represents 10.24m, so we need 0.76 more to get to 11m, @ 4cm per R value that is R=19; 4×19=76).

It is easy to work out this sequence on a spreadsheet. The problem I have is that I haven’t found a tool which can do the palette swap for more than 256 colour palettes, which means that I can only work with regions with height under 256m. Fortunately, most of southern England and northern France fits this criterion, and the spots in SW England which go over the limit are small enough that they can be fixed afterward by hand. So I will describe here how I do this process with the stated limitations. Basically it involves converting the height BMP into an indexed 256 colour image, thereby losing the >256m information, converting that palette to the one I constructed from the spreadsheet, then resaving the result as a 24-bit targa or PNG file which mtt2 will accept for height values.

In gimp, I do this the following way: first, I need to create a 256 colour greenscale palette, which i can force gimp to use when converting the BMP to palettized form, so that I know I’ve kept the <256m data in the correct order. If I don’t do this, gimp creates a rather imaginative green palette of its own invention which does not have the colours strictly incrementing, presumably as it’s trying to incorporate the >256m colours as well. Anyway, creating this palette in gimp is easy. Make a new image 257x4pixels, and use the colour gradient function to make a green smear from black to green 255 across it. Set image mode to indexed, so we have all 255 greens on the palette. In the index palette dialog, choose “create optimum palette”, 256 colours, no dithering, do not discard unused colours. Now call up the colour map dialog (make sure you’ve got it right way round, with black at the top and green at the bottom – I think this is always the case), and edit the black (first) index, to full blue (R0, G0, B255) to match the height BMP, then save the palette by opening the palette dialog and choosing import. Call it BoBGreenscale or something similar. OK, now we’re ready to convert the BMP to indexed. Load the BMP, set image mode to indexed. This time, choose “use custom palette”, no dithering, don’t discard unused colours, and select the palette you’ve just saved (by clicking on the little coloured palette glyph). gimp will assign the index numbers the best it can – when it finds heights above 256m, it will disregard the red bits and choose the closest green shade. The result for our heightmap will be that at these points height wraps back to zero, and starts climbing from there, at those locations. Now save the resulting indexed image as a pcx file. Call it GreenscaleLayer or something.

Now, I have built a red index colour palette, called BoBMetreHtPal.pal, representing 1 metre steps, in mtt2 .pal form. It was generated using a spreadsheet, then a bit of hand editing (the palette file is plaintext), you can look at it in notepad to see, the form is Blue Red Green<return> for each line. It is included with this tutorial here. Our (almost) last step is to convert the palette in our intermediate height pcx to this one. This is easy to do with mtt2, just do the command

mtt2 -d4r GreenscaleLayer.pcx -r BoBMetreHtPal.pal -w RedscaleLayer.pcx

and now we have a pcx with the right colours. This can be converted to RGB mode in your image editor, then saved to a tga file (png file if you’re using gimp) for use in terrain compiling, or dropped back onto the stack in the same position as the source greenscale layer, if further editing is needed on it.

Unless you manipulate the “Bfield” files (outside the scope of this tutorial), you must remember to to always respect the height of the airfields. Usually the fields are surrounded in the landuse map by two roughly concentric circles of fake line, and the white dots on those lines must retain their original associated heightcolour. The easiest way to do this is to have the original heightmap in your stack, and select and paste the heights for these regions from that layer to the new one.

c) Preparing an edited heightmap for compiling

If you have made some large changes to your heightmap file, and you are now ready to compile it back into the terrain, you must be careful of creating cut seams on the terrain – sudden discontinuities, which in BoB2 result in the ocean surface showing through the tear. Generally, when you make a change in the height of a point, the compile process smooths out the change into the surrounding terrain. However, this won’t happen if the change occurs on the edge of the block of terrain you are editing – smoothing is only done within your block, then it is planted back into the existing terrain without any attempt to match the new edge to the old, so you must retain the edge of your heightmap at the values it had before your edit. The way to do this is to simply save the edge of the original heightmap, on your block, so that your edits are completely within the block and surrounded by original height points. The easiest way to do this is to simply extract an edit block that is one Rowan tile (256 pixels) larger than you intend to edit, all the way around. Then trim your SRTM layer to the real working size, and when your are finished, merge the SRTM layer with the larger original tga. You will note that in the Boscombe example I’ve shown here, I have done this – the greenscale layer is inset 256 pixels all around. The finished png file I will use for the compile looks like this:

The interface between the old heightmap and the new looks disjointed, but because it is all within the edited block, it will be seamlessly smoothed together, while the old height of the block edge will fit sealessly into the existing terrain.
Other heightmapping notes:

* Heightmapping notes for gimp users: Using gimp PNG files instead of targas: again, you can use the mtt2 extract commands as they are given in the tutorial, and if you are not going to edit the heightmap, but only work on the landuse, you don’t need to load your targa into gimp, so just leave it, and use it when reloading the terrain into mtt2 using the commands just as they are given in the tutorial. However, if you do load the targa into gimp and edit it, you must then save it with extension .png instead of .tga. A gimp file save Options dialog will appear; you should choose the default options, which are: No Interlace; No Background; No Gamma; No Offset; Save Resolution; Save Time (this one is probably not critical); Compression Level 9. When loading the changes back into the terrain via mtt2, the command given in the tutorial is of the form

[whatever_folder_path]\mtt2>mtt2 -d4r heightmap.tga -r landuse.pcx -qbw [StartX] [StartY]

To alter this command to use a heightmap.png file instead, all we have to do is replace the file extension to match our new heightmap file format, like so:

[whatever_folder_path]\mtt2>mtt2 -d4r heightmap.png -r landuse.pcx -qbw [StartX] [StartY]

Easy! mtt2 knows that .pcx is for landuse, and .png and .tga are for height. Also, in this command, the first file is always height.

* You must not alter the height or flatness of airfields. Retain the original height out beyond the outer blue fake line ring surrounding the field.


11) Object Placement

There are lots of 3D ground objects which can be placed on the terrain. There is a catalog which lists what they are, and a series of pics showing them, which can be found on the web at this location: BoBII Objects Catalogue . There are two ways to place objects, one which has hooks into various parts of the game engine, and creates objects which can be detected, targetted, and damaged, which is called the “battlefield” method, and requires binary files to be created in the “Battlefield” directory. The other way is much simpler, but the objects created are just for looks, and don’t participate further. You can even fly through them without consequence. Stickman is the current expert on this process, and his new guide can be found here:


12) Now What?

So you have accomplished a mod, tried it out in game, and it works. How can you share it? Clearly, terrain texture image files can be simply posted and shared, and there
are some already available “out there”. But if you’ve done a real terrain regions (land use, geography) mod, you have now a rewritten


totalling more than 40MB. It is not a matter of choosing to add a minor item by adding a small file. These files completely replace the whole map for the sim. Thus, up til now, the very few of us who have done these sorts of mods for the user community have chosen to collect our work together, as pcx and tga files, and compile them all into one fileset, and offer a single product for download, along with a new fartiles.bin. A2A (then-Shockwave) recognized the value of this work by choosing to include our upgrade in their game patches, v2.04 to 2.06. Since then, we have continued to contribute to the game patches which are now released under the BDG banner. For now, this is the method we use, coordinating our efforts into a single result. To connect with us, just check in at the A2A BoBII forum. If more modders appear, we or they may develop other strategies.


13) BoB Discussion Fora, and other useful links

Places you may find folks who can help with your modding projects. Also good places to bitch at me about writing an incomprehensible terrain modding guide…

* The A2A Simulations Community; BOB2 General Discussion This is now our home base, thanks to the generous hospitality of our host, Scott, owner of A2A Simulations (Formerly Shockwave Productions – the name change is not a buy-out, it was a decision based on the growing profile of other registered users of the name in somewhat related fields)

* SimHQ Forum: Battle of Britain + Battle of Britain 2: Wings of Victory

* An online third party help for the Gimp – looks much more thorough than the official help files/site:

(Also, I can offer a major useful suggestion for beginning Gimp users: read through all the “tips of the day” – you can even pull up the file in a browser. It contains lots of instructions for basic operation and navigation, which you won’t find by reading through the accompanying “help files”, which are mostly useless.)

* Here’s another handy little item, a Windows “Powertoy” which opens a command window in a folder you’ve highlighted with file manager (it appears as a right-click-menu item). Very useful for launching mtt2, as you don’t have to cd from the default c:\ location dos windows usually open at.. Called “Open Command Window Here”, cleverly enough, and found on this page:


Concluding note: Please don’t be shy about dropping by the A2A forum and asking for help, or giving feedback on the usefulness of this article. I can’t improve it if I don’t know what problems you have with it.


Acknowledgements: as noted, the tutorial authors, Not Enough Red (NER) and DonnyBrooke/Don E Brooke, who got me started in this, as well as the redoubtable Osram, main stalwart of the BDG, who came to the rescue many times figuring out why things didn’t seem to be working the way they were supposed to. Also, for v1.03, I obviously relied heavily on the work done by HurricaneHicken, who has managed to advance this system much farther than I have.

Revision History

– Fourth Draft, Nov 9/05 = public release v1.0
– v1.01 – Mar 5/06: minor update: fixed underline-to-hyphen link problems; repaired errors in BoBpal1.pcx colour indexing,
– v1.02 – July 31/06: edited links due to SimHQ downloads being offline
– v1.03 – Apr 14 /07: A major update.
*Introduced the use of .png files for heightmapping,
*and the howto for importing SRTM satellite height data.
*Also added (and corrected) a considerable number of new minor observations in the “Other notes” section.
*Provided a (possibly final) upgrade to the BoBpal1.pcx and newpal.pal files to account for more colour uses discovered.
*A little intro to the Cities Revealed aerial photo database
– v2.0 – Nov /08: Massively Reworked: expanded, integrated into a single html file, largely rewritten with much more attention to beginner issues.
– v2.00a- Dec /08: Extremely minor tweaks to the above file, only mentioned because it changes the file datestamp
– v2.10 – Oct /12: A minor upgrade, mainly to update palette file and map with new assignments for France texture file, and amended various points where changes have been made to the BoB2 terrain renderer, plus changes to website links. May not have caught all the items needing updating…


14) Appendix – A catalog of a few mtt2 error messages and their likely cures

First, I’ll quote Donny Brooke one more time:


So, you’ve made your changes and are ready to insert your new PCX file back into the DAT file.  You will get errors.  It’s inevitable, like sunshine and rain.  Here is a sample.

Lost my way following edge  Starts (1175,3074) Direction 4 Ends (1129,3073)
Lost my way following edge  Starts (1278,3138) Direction 1 Ends (1280,3164).
Lost my way following edge  Starts (1552,3225) Direction 3 Ends (1539,3231)…..
Lost my way following edge  Starts (1201,3072) Direction 4 Ends (1195,3072).
Lost my way following edge  Starts (1591,2856) Direction 6 Ends (1560,2816).
Lost my way following edge  Starts (1112,3072) Direction 7 Ends (1129,3072)
Lost my way following edge  Starts (1591,2856) Direction 6 Ends (1560,2816)…..
Lost my way following edge  Starts (1550,2803) Direction 1 Ends (1560,2816)

The first thing you notice is that most are “Lost my way” errors, which means that something is interfering with the program following the lines.  The numbers in parentheses are coordinates.  Note that there are “Start” and an “End” coordinates, which you will find correspond to pixel points in your drawing.  Merely find the coordinate point and follow it to the end, which is usually the problem area.  The “direction” is based on a square, and the direction points correspond like this:

Note that sometimes the program will give you several errors for the same problem point, so that makes things a little easier.

Here are some more. These errors are currently in no particular order, maybe I’ll figure one out eventually…

Fatal error in PointsConnected at x=512, y=2048
connecting points in uncompression, a=12, b=0

This error occurs, if you are fortunate, and mostly in second level compile, when you have an unlinked “island”, in the tile above the one named …err, numbered. That is, in this example, the tile 2 over (2×256=512) and 8 down (8×256=2048) is just beyond the problem tile, which is thus at 2 over and 7 down. mtt2 looks at tiles in order down the left column from the top, then down the second left column, and so on across the image to end on the bottom right tile.

Failed triangler with 0 fans: Square (1024,256): (1280,471),(1254,470),(1280,471) colour: 33

Another second level compile error. This is an interesting error. If you try to ignore this and compile, you will get a magenta colour in a region somewhere around the cited location. The problem is that mtt2 is having trouble trying to figure out how to build its 3D surface facets. It seems to make this complaint when a region of one colour is closely surrounded by a narrow region of another colour. The cure is to add some fake lines between the inner and outer boundaries, to help it figure out where to put the edges of its triangular facets. Usually about four lines are enough.

Polygon wiv RouteCol(146) at (433,438)
Unable to identify any point as one wiv correct col (from point (433,438))
Polygon wiv RouteCol(146) at (441,330)
Unable to identify any point as one wiv correct col (from point (441,330))

I’ve mentioned this error in the tutorial, as a fairly common first level compile error, when it occurs once. However, if you see a string of these, as many as 20 or 40 in a row, it is most likely because of a bug in mtt2’s error reporting: what’s actually happened is that just before mtt2 looked at the first point it’s complaining about, it had encountered 251 white dots in a single tile. If it encounters 246 dots (not including the four corners) it will not complain, saying something like

21 edge points defined. 246 total points defined.

and all is well. But at 247 dots, it announces

21 edge points defined. 247 total points defined.
TOO MANY POINTS!!! (251,0)
There were errors!

It adds the 4 corner points to the 247 points it has counted, and announces that there are TOO MANY POINTS! at 251. This is completely reasonable behaviour, and it continues for 248, 249, 250, and 251, reporting too many points of 252, 253, 254, and 255. However, it never gets to “252 points defined”. At that point, it stops saying “TOO MANY POINTS”, and reports

21 edge points defined. -4 total points defined.

At this point, as it has failed to recognize there are too many points, it starts spitting out Poly wiv RouteCol errors for each point it encounters in the tile beyond 251.
From here on, the number of total points defined climbs again to 251 and wraps to -4 again, for more dots found on the tile, and “too many points” is only reported when that number is between 247 and 251. The rest of the time, the error shows up as a string of Polygon wiv RouteCol errors, one for each dot beyond 251. If any white dot is removed from the left side of the tile, the first RouteCol error in the list disappears, while the rest remain – mtt2 has gotten one dot further through the tile before starting to complain.

Obviously, when you encounter this behaviour, the cure is to remove dots until you are below 247 for the whole tile.

abnormal termination

This happens in a lot of different cases, sort of a catch-all when no other specific error report is generated, but one error which gives this is when you’ve inadvertantly made your image too large – like 1025 pixels instead of 1024 along one axis. This can happen when you are cropping a chunk out of a bigger pcx, then you have to build the magenta border around it by hand, which opens the possibility of human error.

Varieties of the common “lost my way” error

If you get one of these, and you can’t see anything obviously wrong with the line in question, even after a careful going over, you may be getting errant “poly” pixels sitting beside the line. If the line is dividing two regions with extremely similar, but distinct, colours, you may have a pixel or two of one colour strayed onto the other side of the line, which will throw mtt2 into confusion. It may be necessary, for some pairs of colours, to do things like darkening the room and zooming in close to detect the difference between the colours and root out the offending pixels. Pairs like index 32 and 65, or 37 and 70, are brutal. You can always area fill with a different colour to improve the contrast, then return to the original colour after troubleshooting.