Muizer's guide to battlemap modification

[Ramashan]

However, box 6 and what on earth ground type distribution is centered on a "grass_long" gridcell means, is so-far eluding me.

Forest_sparse is 'SHALE' 'NORMAL'

If you go to the table in Figure 7 Box 6 you'll see SHALE is 5th down (since the numbering starts at '0' SWAMP is 0 making SHALE = 4)

Then if you go across the columns to the right you see NORMAL is 4th over (again, the numbering actually starts at '0' making QUAL_NONE = 0 and QUAL_NORMAL = 3)

So, if you go across on the SHALE row till you get to the normal column, you will see they intersect at: grass_long

Does this make more sense?

[Muizer]

Hi. Sorry to let you guys struggle with this. Haven't looked at this in a while (used it plenty though). If it's any help, I've added an xls sheet for download that contains the addresses of all values in descr_geography.db. Find the parameter you want to edit and note the address. In the HEX editor, got to the address drop down menu and select "go to". Make sure "decimal" radio button is checked. Enter the address and click "OK".

As for how to use it, I may have had some new insights since writing the tutorial but nothing very concrete. I should look over the tutorial again soon. From practice I can say there are so many interactions to consider that editing climate/groundtype combos is more art than science. LOTS of trial and error here.

Forest_sparse is 'SHALE' 'NORMAL'



If you go to the table in Figure 7 Box 6 you'll see SHALE is 5th down (since the numbering starts at '0' SWAMP is 0 making SHALE = 4)



Then if you go across the columns to the right you see NORMAL is 4th over (again, the numbering actually starts at '0' making QUAL_NONE = 0 and QUAL_NORMAL = 3)



So, if you go across on the SHALE row till you get to the normal column, you will see they intersect at: grass_long



Does this make more sense?

That's it. Best forget about the names like "shale" and "soil" though. It's the cell content of the coordinate that matters: it would be all you would see if there were no random or slope effect variance.

[makanyane]

ah right, getting there I'd been dismissing the two entries between fade_in and std_dev as junk, oops. That is making some more sense now, thanks both. And many thanks for the excel sheet Muizer, that's wonderful I've been screen-shotting bits and trying to mark them up with comments, but that fixes problem of identifying things completely (it hadn't occurred to me to look for cell numbers)

One thing I did find that might be useful (not sure if it got mentioned before) but to get it to read new battlemap textures from mod-folder if you change the paths from
terrain/battlefield/texture_name.tga
to
terrain/xxxxxxxxxxx/texture_name.tga
where xxxxxxxxxxx is same character length as battlefield and make my_mod/data/terrain/xxxxxxxxxxx folder in your modfolder for the new textures (obviously assuming you put them there) it reads them from there instead of needing to be mod_0.pak'ed
(if everyone else knew of easier way of doing that I'd probably prefer you didn't smirk too much as it took me a while to find that one)

and Muizer, I'd agree on the more art than science bit, once you get into detail most of the things to do with mapping and battlemaps they seem to work that way - somewhere between very irritating and very interesting...

[Ramashan]

Thanks for the Excel sheet Muizer!

I can't wait to get a new computer now so I can play around with this more. My old one literally crashed as soon as I figured out how to navigate around the HEX editor.

And thanks for the tip on the terrain folder Makanyane. I will experiment with everything I have learned here. Please keep us posted on anything more you discover and I promise to do the same.

[makanyane]

I think I've finally managed to understand most of this, one interesting discovery was that the BGR colour you set for the distant view also turns up as the grass colour for the equivalent terrain in the foreground, which rather messed up one of my little plans!

The thing I haven't grasped is how it decides to vary the colours used on slopes. Textures on flat areas seem to be behaving logically in accordance with the position selected in the table in box 6. But the colours introduced on the slopes by upping the standard deviation don't seem to bear any relation to that or things adjacent to it...

Does anyone understand how they get selected?

(all I'm actually trying to do is get a bit of red to turn up on distant view of my mountains in volcanic region. I can do that but I need to be able to make sure its only on a specific terrain type which doesn't get used elsewhere in the climate - sounded like a simple idea about 3 days ago )

EDIT: The part where I want the controlled colour seems to be using the sand colour regardless of what I switch the theoretical position to.

[captainbloodloss]

Don't mean to bump this month old thread, but is there any way to add small hills to maps? Small ones, maybe on average only 15 feet high to break up the monotony of a never-ending grassy plain and make for some good defensive positions.

[Muizer]

Don't mean to bump this month old thread, but is there any way to add small hills to maps? Small ones, maybe on average only 15 feet high to break up the monotony of a never-ending grassy plain and make for some good defensive positions.

Not to the extent present in M2TW (cliffs on the battlemap), but yes you can do something and editing descr_geography.db is the way to do it. It governs short range terrain variability (separately for each climate/ground type combination). The most obvious application in Vanilla is the rolling terrain in the sandy desert.

[Muizer]

updated (see post 2)

[Éorl]

Just took a quick look through the last posts, maybe this could help:

I did this last night, not having read the update to this tutorial.

I stopped trying to set up a new climate, and set out to mold an existing climate into something else instead - or to put it somewhat less abstract: I needed another dense forest climate for The Fourth Age 3.0 besides the existing deep forest and open forest climates so that I can have the old legendary forests like Fangorn or Lorien grow on our incarnation of Middle-earth and make them look different (with unique models) compared to the existing forest climates. I chose the highland climate to be shaped into the 'legendary forest climate', since the alpine and open forest climates could replace it well on our map. Problem was: no matter how much dense forest ground type I put in the highland areas, the forests rendered on the battlemap didn't even come close to the density and dominance of those rendered by the original deep forest and open forest climates. So I inspected the descr_geography.db, hoping to find a clue, and compared it with what is documented in the descr_geography.txt.


The important table relating to the dominance of groundtypes is the following table (here: the vanilla highland entry in the .txt file):



Apparently, dense_forest has only three entries here and unsurprisingly is not very dominant.

Inspecting the gridcells following the texture paths for highland groundtypes in the .db file, I stumbled upon numbers in single byte format repeated every fourth gridcell, seperated by 3 '0'-gridcells (single byte), starting with a '6' here:



...and 4 gridcells further another '6'...



...and two more '6s' 4 gridcells further each. Moving the cursor further four gridcells from the fourth '6' revealed a '9':



At that moment it occured to me that the first 4 '6s' could maybe relate to the first 4 'mud' entries in the first row of the table in the corresponding .txt file, which I always use for reference, with the '9' relating to the 5th entry in the first row - grass_short. Moving the cursor another 4 gridcells revealed another '9', obviously relating to the 6th entry in the first row - grass_short again. I immediately began to document the numbers the data inspector revealed every 4th gridcell, noting them in order in front of the groundtypes documented in the .txt file. The result:



So, each number in the .db file relates to a certain groundtype as documented in the corresponding .txt file. I happily proceeded hex-editing the numbers in the .db file to represent this:



Now let's compare the vanilla highland version with the new one I just made for The Fourth Age 3.0 WIP in-game. First, using vanilla's descr_geography.db - the location is labelled 'sparse forest' on the battle editor map_composite. That's a forest? No!



Here's exactly the same location, same camera angle, using the same map.rwm and whatever, only difference is the descr_geography.db, edited as explained above. Now that's a forest!



I guess the implications for changing the look of climates even further are obvious.


Enjoy!

[Muizer]

So those ground type matrices are in the .db after all! Good find. Modifying them will be tricky, but could be worthwhile.

[RedFox]

An easy-to-use tool could be easily written to do all this without the need of manual hex editing. Would make development a lot more easier.

[Ramashan]

Is that a job you want to take on Red Fox?

Great find Eorl!

[Squid]

You kidding, I've looked at the DB and though of writing something and it scares me away so I'd imagine it would scare most tool makers away.

[tone]

Great work, Eorl.

How much forest ground type is used in any climate's battlemap is also dependent on how things are setup in the lookup tables.

The result is illustrated in Figure 4. As you can see, the Sparse Forest summer textures indicate uniformal grass coverage. Odd as this may seem for a ground type "sparse forest" this is indeed the intended effect. In figure Figure 7 box 7, we find that sparse forest has a hardness "shale" and quality "normal". When we consult the table shown in Figure 7 box 6, we find that the ground type distribution is centered on a "grass_long" gridcell. Remember that in the .db file rows and columns are numbered from 0 to 5, so the coordinates of this gridcell are 4(row) by 3 (column). These are indeed the numbers (in byte format) found for Sparse Forest in the .db equivalent of Figure 7, box 7. Beware that different climates can have different "lookup tables"! The tables themselves, it seems, cannot be modified.

So basically what I'm saying is that you can adjust things by centering the table more towards the forest end of the spectrum.

[Squid]

Yes, but editing the table table only does something if you either those entries that are mapped to by the conversion/generation tables or alter those tables to point to other changes you've made.

What I'm curious about is do the actual column/row headers of the table table actually mean anything. In other words do we want to use up all the high and very high slots in the table before using lower quality slots?

[Squid]

Well I'll add my own two bits of information about battle map modification to this thread:

Note: Any number that starts with 0x is referring to a hexidecimal number and not a decimal number, so 0x10 is not 10 but is 16.

1. Textures are not of fixed length and can be altered
   
   First lets look at what exactly we see in descr_geography.db
   
   
   
   On the left we see the hexidemical representation of descr_geography.db, on the right the text representation.
   
   I've highlighted the byte located 2 bytes before the first texture entry (terrain/battlefield/test_climate/summer/oz_medi_rock.tga). The hex value is 0x39, if you look at the Data Inspector window you'll see that this translates into 57 in decimal. Now if you could the number of characters in the texture (i.e. the number of characters in terrain/battlefield/test_climate/summer/oz_medi_rock.tga) you come up with 56 characters. If you notice there's also a byte with the value of 0 immediately after the texture to make 57, for those with programing background this is a c style string in that it is null terminated. So if you want to name your texture something that is shorter or longer than the texture you are changing just make sure to update the string length located two bytes before the texture starts. Since the texture length is located in a single byte (though I'm a little suspicious of that 1 in the byte before the length) this means that the maximum size of a texture is 254 characters + 1 for the 0 (or null character) at the end which gives 255 characters or a hex value of 0xFF the largest possible.
   
   
2. The conversion table can be altered
   
   Now this is slightly more complex and took me a while to figure out what CA had done with this part. So again here's an image of what we see in the table table and the conversion table in descr_geography.txt for the default climate.
   
   

       table
       {    ;            QUAL_NONE    QUAL_VERY_LOW    QUAL_LOW        QUAL_NORMAL        QUAL_HIGH        QUAL_VERY_HIGH
           ;            ---------    -------------    --------        -----------        ---------        --------------
   
           SWAMP        rock        mud                swamp            swamp            grass_short        shrub_dense            ; . x x . . .
           SAND        rock        sand_caked        sand            grass_dry        shrub_dense        forest_dense        ; . . x x . .
           SOIL        rock        grass_short        grass_long        shrub_dense        forest_dense    forest_dense        ; . x . x . x
           CLAY        dirt        grass_long        grass_long        grass_long        forest_dense    forest_dense        ; x . . x . .
           SHALE        rock        gravel            grass_dry        grass_long        shrub_dense        forest_dense        ; . x . . . . 
           ROCK        rock        gravel            grass_dry        grass_short        grass_short        grass_long            ; x . . . . . 
       }
   
       conversion
       {
           rock            ROCK    NONE
           gravel            SHALE    VERY_LOW
           sand_caked        SAND    LOW
           sand            SAND    LOW
           sand_blown        SAND    LOW
           dirt            CLAY    NONE
           mud                SWAMP    VERY_LOW
           swamp            SWAMP    LOW
           grass_dry        SAND    NORMAL
           grass_short        SOIL    VERY_LOW
           grass_long        CLAY    NORMAL
           shrub_sparse    SOIL    NORMAL
           shrub_dense        SOIL    NORMAL
           forest_sparse    SOIL    VERY_HIGH
           forest_dense    SOIL    VERY_HIGH
       }

   So looking at the conversion table, it is a list of, I don't know what, but is maps items to textures through the table table. After Eorl posted his bit about altering the table table, I looked to see if similar alteration could be made to the conversion table, and Muzier has already shown how to modify the generation table.
   
   Here's the relevant section of descr_geography.db:
   
   
   The highlighted cell is the last entry in the table table, this can be verified because grass_long is the 10th texture listed (i.e. 0x0a), and the integer before (i.e. 4 bytes earlier) is 9 which is grass short. Now skip one integer (4 bytes) as seperation, and now the data in the conversion table is listed in three byte groupings with a one 0 byte between for spacing. The three bytes in each grouping are the climate, the quality, and the ground from left to right. So starting two bytes to right we have a grouping of 3 zeros.
   
   So the first 3 byte grouping is (0, 0, 0x50) since programatically we count from 0 so the first culture would be labelled 0, 0 for quality corresponds to NONE, which matches, but the 0x50 stumped me for a while, until I realized the 5 mapped to ROCK. So for some reason CA when recording this information (and only this information as this notation is not used anywhere else in the file), switched the lower 4 bits and upper 4 bits of the number. To verify this lets look at the next 3 byte grouping, so skip one byte after the 0x50 and we get the three bytes (0, 1, 0x40) which maps to VERY_LOW and SHALE.

Hope this is of some use, and if someone can tell me what the conversion table does, Muzier didn't even mention it, but it obviously means something. There are a few bits of information I don't yet understand, but I think I know enough to perhaps work on a db editor.

[tone]

I think what you have to think is that quality applies to the quality of the ground rather than a texture, which probably relates in some way to the degree of slope. So you see that rocky/mud etc are over towards the left in the lower quality end of the spectrum, whereas forest is over at the right end. So i guess what you can do from this is alter the distribution of different ground types on slopes....say you want forests to be mainly on sloping parts of the battlemap rather than flat ground, for example.

[Lo_ZaL]

How can I add object how ''cliff'' in the game usable also in the battle editor?

[The Spartan Warlord]

Now we can make battles Barbarians vs. Romans more realistic...

GREAT!!!

[Squid]

I think what you have to think is that quality applies to the quality of the ground rather than a texture, which probably relates in some way to the degree of slope. So you see that rocky/mud etc are over towards the left in the lower quality end of the spectrum, whereas forest is over at the right end. So i guess what you can do from this is alter the distribution of different ground types on slopes....say you want forests to be mainly on sloping parts of the battlemap rather than flat ground, for example.

My question really is I suppose if I have two dense forest entries in the table table one in quality none the other in quality very high what difference is there from pointing entries in the conversion table and the generation table to one or the other?