Fun -n- games with TPG2 and the sector editor.

How this document is organized:

1. Conventions used;
2. The structure of TPG2
3. Map structure of TPG2.
4. Tutorial: how to fiddle with the maps .scn files.
5. How to use these techniques in scenario design.
6. The future.

I. Terminology used:

hx

hexadecimal

hex

a map hex

nibble

a half a byte, corresponding to a single hx digit. So, given for example, the hx number 13 (19 decimal), the left nibble would be 1 and the right 3.

SCENEDIT

the TPG2 Scenario Builder

DISKEDIT

A sector editor

.scn file

the scenario file

.sav file

a saved game

.rcn file

recon map

The information you need to read in II and III before jumping into the tutorial is indicated in bold. Indications of issues yet to be determined are in italics.
 

A few additional comments:
I'm looking over this, and in some ways it's a pretentious mess.  To help you through the maze, here's what I'm trying to do in section II:
One of the major areas of confusion has been with what is and what isn't possible to do with the sector editor.  What I try to explain is why manipulating the map can do certain things, such as make a 3-damage point bridge, but not others, such as make elephant tanks move like AC/MGs.  To explain this, I discuss rules (how the game works), specifications (what the map has to have for it to be valid) and conventions (what SCENEDIT does, often for very sound reasons, but which it doesn't have to do).  Thus, in the bridge example, a rule is that engineers cannot build light bridges of more than one point, a specification would be that, for the map to work, the number of hexes with damage points and their value (1, 2 or 3) on the map must remain the same, and a convention is that these damage point hexes must correspond to bridges, and specifically to bridges of a certain type.

II. The structure of TPG2 and scenarios: rules and conventions

I see two consequences of this: one is that in TPG2 it is necessary to distinguish between rules pertaining to how the simulation functions, and ones pertaining to how the interface works. The other is that since simulation and interface are intertwined, the necessities of one often dictate the form of the other. In our case, the need to represent the map in a quick manner requires the substitution the use design conventions for programmed rules. When you combine the two consequences, you reach the conclusion: using a sector editor, and modifying the map alone, you can violate purely aesthetic conventions at will, and, with some skill and experience, some functional ones.

With regards to the first consequence: TPG2 as a simulation has a master set of rules it applies in an order established by the scenario (.scn file), which it, as interface, presents to the user in a comprehensible fashion. This means that the game expresses both functional (simulation) and aesthetic (interface/user) rules. For example, a functional rule is that a light tank has 7 movement points; an aesthetic rule is that it has a cross on it when said points are expended. So too for the map: a road will have as functional rule, "A unit moving on to it from an adjacent road hex will expend one half movement point", and the aesthetic rule "if two road hexes are adjacent, the roads must connect".

This brings me to the second point: how do we implement such a rule? One could set up the map such that there would be a single flag: "is/is not a road hex". That would suffice for the functional rule. Then, one could make the interface "connect the dots" and, when generating the map, render the road hexes as all connected. That way, we satisfy the aesthetic rule "if two road hexes are adjacent, the roads must connect". But in that case, one would be making the interface do a lot of work; space isn't at such a premium that we want the computer to recalculate the map every time we load a scenario. So, instead, we set up a table of images that corresponds to the various road pieces, and require that every map loaded have roads that connect. Now, what we've done is replaced a "rule" with a "convention"; There can exist maps with road hexes that don't connect, but in practice they don't, because maps are not normally designed that way.

This talk about roads is just one example of a "convention" in TPG2. (in violation of the "aesthetic rule" above). In fact, the whole .scn file only makes sense to TPG2 inasmuch as it follows certain conventions: it is also a convention, for example, that the map be of a certain size. So, let's call this latter group of conventions, the essential ones, without which the .scn file won't work, "specifications."

Enter the scenario builder (SCENEDIT). The scenario builder's job is create .scn files that are comprehensible to the simulation, the interface, and the user. That is, it creates files according to specifications and conventions. But we, as designers, may decide that certain aesthetic or functional conventions related to the map are too restrictive. In order to do this, however, we must know how the map is arranged.

III. The map.

Map Organization: Imagine the tpg2 map: It's in hexes, and there are straight vertical rows, but to go from left to right you have to bounce up and down hexes. Now the computer wants to store this information in a grid. So, we're gonna hafta put some horizontal lines on the map. The way TPG2 does this is by considering only half-hexes at a time. That is, if you go from left to right, bouncing up and down, and take those hexes, you will have one continuous path composed of two interlocking (zipper) rows of hexes. Where these hexes interlock is the middle: the top half of the lower row is always in contact with the bottom half of the row above. Thus, every hex is represented twice: there's a top half hex and a bottom half hex.

In short, the TPG2 interface, when drawing the map, determines to the half-hex where the visible screen begins, and the shoots through the map, drawing one half-hex row at a time. It does not need to jump up and down or left and right to put the hexes on the board.

What this means is that, on the map a hex is represented in two places: in one place for its top half (what I called in previous posts the "static hex") and in another, exactly one half-hex row down (what I referred to as the "dynamic hex"). Note: it is possible to put an object in one half hex, but not the other. Then all one sees is a fragmentary object. Often this seems to violate specs, but if any of you find a good use for it, feel free to investigate.

In what follows, therefore, I use "half-hex row" to refer one row of such "zippered" half-hexes. I use "hex row" for a latitudinal discrete row of full hexes. In English, by this I mean a straight row of hexes, none of which therefore are touching each other. (to put it by mental exercise: if you take every other column of the map, each one of their rows is a "hex row")

Each half-hex is divided into 8 bytes, and each half-hex row is 82 fields long, for 656 bytes (290 hx). Frankly, from the point of view of a sector editor, things couldn't be better. Norton DISKEDIT, for example, admits of 21 lines per page, and shows 16 bytes per line. That means that the map appears as two stable columns of data -- each column corresponds to a hex row -- and two page down/up keys (including the usual line that indicates change of sector) will bring you to the next half-hex row.

Ok, so what are the parts of this map? Well, everything you can figure is hex-specific in he game. Here's how a typical hex looks on the sector editor:

0    1  2   3   4  
5   6    7



0010 06 15 73 00 00 0F 00 00     (First half-hex)

...

03A0 04 15 73 00 FF 13 00 00     (Second-half hex)

Positions 0-2: the physical makeup of the hex. The numbers in the top half correspond to the images in the top half, and similarly for the bottom half. In some case, this variation is random; in others it's important, such as when one hex adjoins another of the same time (think of how woods form blobs).

In our case, we've got (top half) 06 - plains, 15-woods that don't connect to any of the three hexes touching the top half, 73 -- a railroad going through the woods, 00 -- I dunno, 0F (or F0, I forget), the hex is part of campaign region number 15. (bottom half hex: 04--plains, 15-woods that don't connect to any of the bottom three hexes, 73-rail, 00, FF--Reinforcement zone number 255, 13 = (1) LOS blocking(?) or "plastic" object (3) Elevation 3 (30 meters on the scope).

The positions are:

0: the background stuff. These are dependent on elevation. There are three half-hex values for each "flatland". 1-3 are sand, 4-6 are grass, 7-9 level 1 hill (50 meters), and so on. At base elevation, there are also values for swamps and fields and probably farmhouses, but I halven't checked these. Ridges form the intermediate (even numbered) elevations. Anyway, I haven't successfully fiddled with changing elevations of things. I think you're stuck with the rules of SCENEDIT

1-2: Object layers. the interface draws 0, then 1(if it not zero), then (if 1 not zero) 2 (if not zero). So, layer 2 will be drawn on top of one which will be drawn on top of 0. If layer 2 exists, but layer 1 doesn't, the interface will not draw it. Nevertheless, it will exist for the simulation (and, if you look in the tiny top-right "thumbnail" you can see it.

In SCENEDIT: the following things are always layer 1:

Cities(01hx ff), Forts(1B or 1Dhx, I forget), Woods(0Chx +/- 1 to 15hx), Airports (ca. 18hx and on up), Rivers (7A - 8Bhx if not beyond).

1. Rail (68-79hx) is layer one, except when running through a city, and when crossing over roads.
2. Roads (56-67hx) appear in layer two when going through woods.
3. Bridges (ca. 28-4?hx) always appear in layer two. Their damage is by convention, not rule. Thus it's governed by the left nibble of byte 6 of the bottom half-hex: this number can be 1 (one damage point) to 3 (as in a rail bridge). You can key in a bridge without this value, and it will work ok (one damage point to destroy, but if engineers try to repair it, weird things happen). The number of hexes with certain values (I dunno if it's hexes or rows. See note below) has to remain the same, otherwise you will get a "scenario corrupt" message. To change the damage value of your bridge is to build a bridge of the damage points desired in a nearby hex on the row, go into DISKEDIT and swap values, then restart SCENEDIT and pave over the undesired bridge.

Nothing in layer 0 ever appears in layers 1-2, or vice versa.

One of the nibbles of top half-hex 5 indicates which campaign region the hex belongs to.

The bottom half-hex, byte 4 is the reinforcement zone number. This is very useful. Control over 255 reinforcement zones means you get to use one byte in the map area as you please. Use it to "paint" your target when the map gets cluttered. E.g., in SCENEDIT in four sequential hexes on the same row, place in order the following reinforcement zones: 72, 69, 82, 69. In DISKEDIT, you those hexes will show up (or rather the bottom half-hexes) when you read "HERE" in vertical letters in the ASCII read out.

Bottom half-hex, byte 5 is particular. It breaks down into two nibbles. The left nibble, when it reads 2hx, it marks the hex as "cratered". Unfortunately, you can't do this without receive a "scenario corrupt" message. As value 1hx this links to something important involved in Cities, Woods, and Forts (perhaps Earl's logic). You can key in these guys and leave this value blank, and they'll function fine, just when they (woods) get shelled they won't have the intermediate "cleared" stage. I dunno what they do for cities, probably control the "burning" aspect. And I'm a loss for forts.  The right nibble is elevation.  In TPG2, if you look on the hex information window, you will see something that reads "Elevation: 30m".  In fact, odd-numbered elevations are flat levels (1-sand, 3-grass, 5-level one hill), and even-numbered ones are slopes.  0 is, of course, ocean.  You're better off changing these with SCENEDIT, since I haven't been able to fiddle with them without getting a scenario corrupt message..

Bottom half-hex, byte 6, left nibble is bridge damage. See the note on bridges above.

The other hexes control a lot of scenario-specific values, such as 1. the number of the unit in the hex (there's a max of 255 units, so we can give one byte to that); current attacker/defender LOS, last-turn LOS (for Earl's cheating, of course), and perhaps other ones as well -- I can imagine an LOS independent of present unit, and present unit LOS. Artillery targeting, wrecks. Maybe even Earl uses a few of these. Fiddlin with them will probably result in a "Scenario corrupt" message.

BTW: A few notes I don't know where else to put.

1. Movement is determined by the most favorable scheme available to a unit; rivers and blown bridges block vehicular movement unless in the other object layer there's a map type that allows movement.
2. When deploying units, Earl determines the possibility of placement from layers 0 and 1, never from 2. So, if you have a river in 2, you can deploy armor on it (but it still has to obey the movement rules). If you have a lovely runway that overlaps a road (and is hence in layer 2, not 1), you're gonna hafta fly 'em in. Still, a highway that widens into a forward airstrip for CAS craft would look pretty cool.

IV. The tutorial

1. First, get the materials I told you to get.
2. Then, at least glance at the bold text stuff above -- try to get a grasp of the terminology I'm using.
3. Now, bring up DOS (unless you're absolutely bound to a 32-bit disk editor. Maybe you hafta be. I dunno. In any case, for this kinda work, it really helps to have DOS with DOSKEY running, since you're gonna be typing in the same commands over and over. So yeah, DOS, DOSKEY, and maybe a cold one.
4. Go into SCENEDIT. Select a new scenario, type grasslands. Savefile name: PUNKROCK
5. Give it a title. Maybe "@TEST", and assign it to group "Special Battlefields": you're gonna be doing plenty of scrolling down as it is, don't make things worse than they need to be.


I. Bridge under water.

6. near the top and the middle of the map (near the top, so you don't have to scroll down so much), run a river straight horizontal (E-W). Build a North-South road, one that starts two hexes above the river, and cuts across to two hexes below, making a nice bridge.
7. Go to "edit reinforcement regions". We're gonna "paint" the bridge. Make the bridge hex itself reinforcement area 69. Go to the preceding hex on the same row (the hex to the left of the hex to the left. Read the note above), and put reinforcement area 71 there. Go to the next hex on the same row over to the left, and put reinforcement area 68 there. Repeat the process for areas 82 and 66, respectively.
8. Save your work and exit.  The included file PUNKROCK.SCN contains what your scenario should look like at this state.
9. MAKE A BACKUP. all you have to do is from the TPG2 directory type "copy scen/PUNKROCK.SCN
10. Start your diskeditor with the file (DISKEDIT SCEN/PUNKROCK.SCN)
11. Scroll down a bit (use either pagedown or the mouse), until you see something like this:

00002D90:   06 00 00 00 00 00 00 00   04 00 00 00
03 00 00 00  ........ ....©

...

00002DA0:   05 00 00 00 00 00 00 00   04 00 00 00 03 00 00 00 
........ ....©

...

(Depending on your editor, the hearts may or may not be there. In any case, the numbers are what's important, not their position in the columns; so they can be shifted over. But if your sector editor reports sixteen bytes per line, the columns will be stable). You are now looking at a TPG2 half row. Scroll down (and then, if you don't find it,back up again), until you find in the ASCII read out on the right, in the column before the hearts, a vertical: BRDGE. (Looks like I forgot the I)
12. The BRDGE is what we did with the reinforcement zones. That column corresponds to the bottom half-hex of the row we "painted". If you don't see BRDGE, but instead BDE or RG, you didn't figure out what I meant by "row".


Anyway, the half-hex data for the hex with the E in it will be:

(the entries in successive rows represent equally likely possibilities)

04 82 38 45 03 00 20 00

05 88

06

 

 

These are: 04-06 the various "grassland" background patters; 82 and 88 are the two E-Wish river hex graphix, 38 is a north-south road bridge, 45 is the reinforcement zone number (ascii E), 03 on the left controls crater, certain plastic map types (woods), and on the right is elevation (30 meters = grassland), 20 indicates a bridge of two points.

Right now, we're just going to run the bridge under the water. If you wanna mess with the other stuff, you're gonna hafta read what I say above about it (and below, when I get around to it).

13. Before changing anything let's find the other half-hex. In DISKEDIT Press "Pageup" twice -- that usually gets us within one or two rows of the target. Otherwise, look at the (offset) location and subtract 290hx from it (on the test file, the offsets are 5530 and 57C0 hx respectively). On that row, in exactly the same column position, look for a field that reads:

04 82 38 00 00 00 00 00

05 88

06

 

 

The 82 or 88 has to be the same as in the lower half-hex; the 04-06 can vary.

14. Turn off the safety of your sector editor. (i.e., take it out of Read Only mode)
15. Over the (82)(88) 38, type in 38 (82)(88)
16. Scroll Down two screens/290hx bytes to the lower half-hex field, and write over that as well 38 (82)(88). If, in the process of scrolling, DISKEDIT asks if you wanna save your sector changes, go ahead and do so.
17. Save your changes, and quit out.
18. Start SCENEDIT, and bring up your scenario. Hold your breath.
19. If you did it right, the scenario will come up. Otherwise, you'll get a corrupt scenario message and have to bring the backup off of ice.
20. Look at the bridge. Pretty cool, huh?

V. How to use these techniques in scenario design.

1.  Start with an idea.  If it's complicated, write out what you plan to do.  If you put your plans for reinforcement strengths, areas, events and the like on paper, you'll find the debugging and tweaking stages much easier.
2. Think about the map.  How do SCENEDIT's restrictions cramp your style?  What are the possibilities offered by DISKEDIT techniques? (If it helps, look at the playable demo prov2.scn I've included.  It demonstrates some of the possibilities).  What are the drawbacks?  Remember that most of the stuff you're changing may involve unwanted consequences.  For example, you can build a really neat lookin' river delta, but Engineers will not be able to build a bridge across it (because of the rule: No engineer may build a bridge next to another one).
3. When building the map, try to make the DISKEDIT changes as early as possible.  Note that the terrain where you want to make the changes must be fixed (any changes to the topography of the target hex, or the adjacent ones, will probly destroy your change), but the whole map doesn't have to be.  It's a lot easier to find your tweaks when most of the map is full of zeroes.  Moreover, the most useful tecnique, that of overlaying, requires some nearby space to assemble the features to be overlapped.  In addition, don't resize the map until after you've established the playable terrain.  The map is always the same size in the disk file.
4. Don't make your life difficult.  Use SCENEDIT as much as possible, and use DISKEDIT only for what's necessary.
5. Always make backups before going into DISKEDIT, and only make small modifications at a time.  One misplaced keystroke can render the map corrupt.  Restoring a backup is much faster than hunting for an error.

Ok, now for some techniques:
Most of these are used in combination.

1. Addition of features.  You go in and type in the new features.  It helps to know the codes, of course.  Moreover, you can only modify object layers 1 and 2, and even then, some things (forests and cities) that change their shape to accommodate adjacent hexes with identical objects, will return corrupt scenarios.  Still, if you know the code, and want to go type in say an airport on a river, go ahead and do so.
2. Burying.  You create a map with a set of features that appear in object level one, go into the editor, and put them in level two.  Since one is blank, the objects will not show up on the recon or regular map; they will, however, appear on the thumbnail map.  This is how I buried the railroad and the forts on The Swamp Monster.  (actually, the forts were a combination of burying and overlaying). I haven't succeeded in burying forests and don't know if it's actually possible.
3. Inversion: this is what we did with the bridge under water tutorial above.  It's simple, and has some uses but again, I haven't succeeded in putting roads under forests.  Airports yes, roads and rivers, no.
4. Point borrowing.  This is actually a variation of overlaying, described below.  If you want to give a bridge a point value other than its conventional one, build a bridge next to it (one or two parallel hexes away) of the point value desired.  Go into SCENEDIT, and swap the lower half-hex, byte six, left nibble values (um, in English, those would be the values that run from 1 to 3 and correspond to the number of damage points the bridge has).  You can also give damage points to non-bridge hexes.  At that point, the hex cannot crater from artillery, it will tick off the points as if it were a bridge.  If, however, it has nothing in object levels one and two, when it runs out of damage points, it will behave as if it were a river hex.
5. Masking: Roads, rivers and rails all have 18 different hex types, and their object codes are adjacent.  Yet roads can go through woods, but rivers and rails can't.  Similarly, rails can go through towns, but rivers and roads cannot.  And you can't have roads on top of roads or rivers on rivers (for those delta/junction effects).  All these problems can be fixed by running a road, river or rail, then going in and changing it to the appropriate type by adding or subtracting 12hx or 24hx.

Conversion chart:
 

6. Overlaying: This is by far the most effective method, since you don't have to remember all those annoying byte values. It's also the way around checksum limitations on bridge values, forest hexes and the like.  What you do is you place the two objects in nearby hexes, preferably on the same row, then go into the editor, and move them the required number of hexes over.  So, for example, if I wanted to put a forest on a hillside, I'd start with SCENEDIT, and build a hill, and put say  three hexes over on the same row the forest I wanted on top of it. Then I'd tag with reinforcement zones the hill and the forest.  Next I'd go into DISKEDIT, find my two objects, and copy the forest three hexes down the same row, on top of the hillside, and delete the old forest.  In our example, that would mean deleting the forest value from top and bottom object layer one in the old half-hexes, copying them to layer one in the new, hillside, half-hexes, and then deleting the #1 from left nibble of bite five, of the old lower half-hex (here would mean changing a 13hx to a 03x), and adding that #1 to the new, hillside lower half-hex (that is, changing a 04hx to a 14hx).  In reality, it's a move that takes 20 seconds with DISKEDIT: you just find the hexes and copy the right information.  I just make it sound complicated.

 

VI.  The Future