Understanding RA format tmp terrain files?

[Allen262]

Quote

Warning what is below maybe weapons grade scary...

To make your own .tmp (RA) that Red Alert 1 uses. You need RA-MIXer v5.1 OR3 http://ra.afraid.org/html/downloads/utilities-2.html This is old school DOS. If your using Win7+ you made be dead in the water. Next it is my bet is that you can't change the size of tile. So if you want to remake the Ant Hill (hill01.tem) into something else your stuck with doing something that is 3x4.

Since I don't think we can change the size of a tile. Find the Ant Hill (hill01.tem) in one the the EXPAND.mixes. Now use Copy as PCX. You can edit this hill01.pcx to what ever you want to look like and save it. Now drag and drop the hill01.pcx on the PCX2RMT.EXE that is inside of RA-MIXer folder (Ramix513). If it works the window will show

Output Information

Filename;      C:\*SOMETHING*\*SOMETHING*\Ramix513\hill01.RMT
Size:          *SOMETHING*
Width:          4  tiles (s)
Height:        3  tiles (s)
Empty Tiles :  0
Converted!

In the Ramix513 folder you will find hill01.RMT. Rename this to hill01.tem. You now have a file you can use in RA1. Put it into you EXPAND.mix and EXPAND2.mix. HOWEVER when you test it in game you will see that you can drive and build all over it. The PCX2RMT.EXE gave it the land characteristic code of [Clear] or [Road].

I have no idea how the land characteristic code work for sure so this is all a guess.

Lets look at the Stock Ant Hill (hill01.tem). At the end of the file when viewed in a hex editor (I'm using Frhed 2.0. It is free) there is a set of number that range depending on tile count (A single tile is 24x24 pixels. The Ant Hill (hill01.tem) has 12 tiles that are aranged 4 across and 3 down so it has 12 pairs of numbers or 12 bytes.

http://imageshack.us/a/img41/5971/anthillakahill01tem.jpg

My guess is each 1 byte (or 2 numbers) is for one tile and this tells the game what that tile is. The Ant Hill has 6 tiles that are passable but only one that you can build on. The MLRS is on it so it has to be [Clear] or [Road]. The others have to be [Rough] or [beach] (unlikely). The parts you can't drive on are [Rock], [Wall] or [River] (unlikely).

Now my untested guess is that the first 4 bytes are for the top 4 tiles, 2nd 4 bytes are mid and last 4 bytes are the bottom. So it would look like this if we laid the bytes out in 4x3 like the Ant Hill is.

0e 08 08 08
0e 08 0e 0e
08 08 0e 03

As we can see it looks a lot like the ingame pic. The APC, Mammys and Hummvee are on 0e and it is Passable but not Buildable. s. 03 is were the MLRS is at and it is Passable AND Buildable. 08 is not passable or buildable. If you made you own Ant Hill using PCX2RMT.EXE and you open it with a hex editor it will show all 09s. After opeing D44.tem. A 1x1 square of road. It is using 09 so it is likely 09 is [Road]

[Nyerguds]

Well, got this so far (thx to iran):

Array at 005FEC94 in RA95.EXE matched to the terrain types array at 00604AE0:

00 = Clear, seems to be used for missing tiles in corners of tilesets, and for random-choosing 1x1 tilesets with multiple tiles in them, like CLEAR1
01 = Clear
02 = Clear
03 = Clear, the one normally used for clear terrain in the terrain files
04 = Clear
05 = Clear
06 = Beach
07 = Clear
08 = Rock
09 = Road
0A = Water
0B = River
0C = Clear
0D = Clear
0E = Rough
0F = Clear

Oh, and  people with Win7+ can invest in a sturdy DosBox boat to stay afloat 

[Nyerguds]

Right. I got working on a tool to fix this stuff. So far, only the parameter reading is done, but that at least means that part is already well-defined:

---

Red Alert Template File Terrain Type Editing Tool
Created by Nyerguds

Basic syntax:
RTMType file -[t|f|1][x][!] [arguments] -d[x] [defaultval]

Parameters:
Types reading:
  t: Give terrain type codes as arguments
  f: Read terrain types from file given as argument
  1: Force tile to 1x1 with multiple entries. Terrain type arg is optional.
Modifiers:
  x : (behind any terrain code reading param) Read byte values (0-F) as codes.
  ! : (behind t or f) Don't abort if amount in file and in types don't match.
Default value:
  d: Specify default value to fill with when using '!' mode. (Can use as -dx)
    If not given, this defaults to Clear (3). Can't be used when using '-1'.
 

Start with -l to list all terrain types and their codes.

Start with -x to show explained examples.

---

Terrain types listing:

Code  Byte  Description
X    0    Unused cell. [Clear] on 1x1 with multiple entries.
C    3    [Clear] Normal clear terrain.
B    6    [beach] Sandy beach. Can't be built on.
I    8    [Rock]  Impassable terrain.
R    9    [Road]  Units move faster on this terrain.
W    A    [Water] Ships can travel over this.
V    B    [River] Ships normally can't travel over this.
H    E    [Rough] Rough terrain. Can't be built on.

---

Examples:

RTMType hill01.tem -t HIIIHIHHIIHC
  Set the terrain types in 'hill01.tem' to the specified type codes.

RTMType hill01.tem -tx e888e8ee88e3
  Set the terrain types in 'hill01.tem' to the specified type bytes.
  Exactly the same effect as above, but can hack in normally-unused types.

RTMType hill01.tem -f! orig\hill01.tem -d I
  Set the terrain types in 'hill01.tem' to the ones set in 'orig\hill01.tem'.
  Continue even if the amount of cells doesn't match. If amount of cells in
  'orig\hill01.tem' is less than in 'hill01.tem', pad with 'Impassable' type.

RTMType arro0001.int -1
  Set the given tile to act as 1x1 tile with different choices. The terrain
  type defaults to 0 since no type codes/bytes are given.

 

[Allen262]

Any thing for TMP ra will help particularly for the interior. I spent a few hours messing around with the 1x1 with multiple cells. I was able to use PCX2RMT than by hex editing cut them apart by coping the need data from the stock files but PCX2RMT won't work with 12 or 13 cell 1x1s. Also hex editing them to work is no fun anyway...

[Nyerguds]

yeeah, and then there's stuff like the file size in the header, and the odd cell counter at the end before the terrain type listings. My tool will hopefully be able to adjust all of that automatically.

 

Do note I'm not sure whether the tool will be able to correctly support these odd 1x1 tiles as input for the file to modify. It'll work as 'souce to take tile info from' though, don't worry... but I still need to figure some things out related to the rest of the end bytes which also change for a 1x1...

[Allen262]

From messing around last night I needed to copy over the top 40 bytes (Header?) than remove any extra bytes PCX2RMT made (if any). Now for arro0001.int I had to copy the last 11 bytes over (offsets 2344 to 2355). The last 5 of them were the for the terrain type and I know it is 6 cells but only has 5 bytes that controll terrain type. If edited the last 6 as if they were terrain type this would make the 6th cell pink when viewed in XCC.

 

GSTR0002.int (8 Cells) worked better. I had to change the top 40 bytes and cut out the extra like before but I only had to set the terrain type by editing the last 7 bytes. Again I know it has 8 cells but 7 bytes that controll terrain type. I tested both files ingame and they did work as I made them both water. Hello inside ships.

[Nyerguds]

Wellll nevermind that, the header actually has a position of the offset of the start of the terrain types (the dword at 0x20).

 

I can just ignore all the rest even when changing between 1x1 repeating and normal types

 

[edit]

 

Wait seriously? that won't help you once you're working with custom graphics that take more or less space than the original. My guess, it'll just fail because the file size in the header is incorrect (dword at 0x0C) after your fix of the footer info. Did you actually test that ingame before replacing its header? Because xcc fails far more easily than the game.

 

Full header:

  0x00 int16 tile_X (always 24)

  0x02 int16 tile_Y (always 24)

  0x04 int32 frames

  0x08 int16 frames_x

  0x0A int16 frames_y

  0x0C int32 file_length

  0x10 int32 offset_endofheader (always 0x28)

  0x14 int32 unkn_00 (seems to always be 0x00000000)

  0x18 int32 unkn_01 (Not a fricking clue what this is. May be a load of boolean options)

  0x1C int32 offset_footer02 // points to some bytes between the start of the footer and the type frames

  0x20 int32 offset_footer03 // offset of the start of the type frames

  0x24 int32 offset_footer01  // offset of the start of the footer

 

Mind you, if it really doesn't work ingame without copying the header, I'll probably have to copy the Mystery Values unkn_00 and unkn_01 when doing an import from file. I may take a look into the xcc code to see if Olaf has more info on them.

 

 

Anyway... I just completed the system to read the types from another file. Now I just have to implement writing it to the given file

[Allen262]

I don't really know what I was doing. With arro0001.int or GSTR0002.int I never changed the number of cell that is was made of I only changed what the cells looked like (graphics). No I did no test ingame before replacing the header (40 bytes.)

[Nyerguds]

Right, well, now you should at least know what to adapt to make it work correctly.

 

Though you're right about pcx2rtm adding a ton of extra stuff that doesn't seem to be needed... not a clue what that's for. Still, as long as it works, I'm staying off that.

[Allen262]

I was looking into interior so White could make his Urban idea. It is a lot of work and I don't know if he would want to do that much. I'll have to PM about it. The interior has many tiles he can use right now that are not 1x1 with multiple cells and if he runs out I can do some for him if he send me the PCXes.

[Nyerguds]

I don't really get your point... if the tiles aren't 1x1-multiples, then there's not much of a problem with them, is there?

Anyway... to help you all along.... here's the finished tool:
http://nyerguds.arsaneus-design.com/cncstuff/rtmtype.zip

Examples:

Convert file to 1x1 with repeating cells:

Import from file: (note: dimensions changing ONLY happens when importing from a file with the same amount of cells, into a 1x1-multiple that thus doesn't have real dimensions)

Use of the '!' switch to force the tool to write the mask regardless of size:

Use of the '!' switch with a file larger than the input, padded with a default value given as hexadecimal

[AchromicWhite]

Looks like a sweet tool Nyer

 

Meh, it's not that much work Allen... you do realise that all of my units are basically drawn pixel by pixel and each contain at LEAST 32 images each, but more likely 64...

This is a piece of cake. The hardest bit will be making new buildings. Although, getting the roads in the right perspective might be a miss, as I want them all the be the same width if they're east to west or north to south.

 

  -Liam

[Nyerguds]

btw, I didn't actually make any parameter to simply fill an entire file with one terrain type, but generally, "-t! I -d I" (force if not enough cells, and set default fill value to the same thing) works pretty well (with both I's replaced with whatever terrain type you want).

 

From messing around last night I needed to copy over the top 40 bytes (Header?) than remove any extra bytes PCX2RMT made (if any). Now for arro0001.int I had to copy the last 11 bytes over (offsets 2344 to 2355). The last 5 of them were the for the terrain type and I know it is 6 cells but only has 5 bytes that controll terrain type.

This is wrong, by the way. 1x1-multiple tileset files only have a single byte of terrain type info. The others you edited were simply part of the information before the terrain type. As I said, you can check where it starts in the header.

[Nyerguds]

Whoops. Fixed a little bug that caused it not to correct the file size in the header when converting back from 1x1 to normal dimensions.

 

Note that the only way to get rid of a file's "1x1-multiple" status is such a dimensions import from another file, since simply giving a types mask won't fix its dimensions, and I can't be arsed to add dimension changing parameters for a case that probably won't ever be used anyway. After all, that's stuff the pcx2rtm converter can already produce.

[Allen262]

Nyerguds:

I don't really know what I was doing.  All guesses. If you tool can do it better than PCX2RMT+Hex Editing it all good in my book.

 

White:

I know but it looks like Nyerguds tool will do eveything with out PCX2RMT+Hex Editing. XD

 

[Killa57]

hum, so yall working to understand the terrain in RA 1? If so will this be able to understand how to fix the soldiers, tanks walking or driving into water?

[Nyerguds]

If it's caused by reconverted terrain, then yes, we know why it happens, and my tool can fix the terrain files

 

Might be an interesting idea to actually READ the stuff in the thread, Killa57.

[Nyerguds]

Tool updated with much-needed file validation. It will now actually give errors instead of crashing when you give a file that doesn't contain a valid RA TMP header and footer.

 

http://nyerguds.arsaneus-design.com/cncstuff/rtmtype.zip

 

Source code: (Lazarus Freepascal project)

http://nyerguds.arsaneus-design.com/cncstuff/source/rtmtype_src.zip

 

[Allen262]

Its not making much since. What dose it do? I must be doing things wrong.

[Nyerguds]

Huh? What do you mean? I just made sure the program now alerts you if the input file wasn't actually an RA TMP file. The old version just crashed on that.

 

You can now also start the program with just one file as argument, and get that file's terrain type info.

[Blade]

Bit of a necro post, but for anyone who stumbles on this thread looking for format info, the actual struct for the header was found by CCHyper in some debug info left in one of the exes and is as follows:

 

struct IControl_Type {

  short Width;

  short Height;

  short Count;

  short Allocated;

  short MapWidth;

  short MapHeight;

  long Size;

  long Icons;

  long Palettes;

  long Remaps;

  long TransFlag;

  long ColorMap;

  long Map;

};

[Allen262]

I'm good with any info that can be added about the TMP set up.

[Nyerguds]

colormap? That makes no sense. That refers to the part of the footer with the terrain types.

 

Odd how the thing previously identified as amount of frames are two shorts (Count and Allocated).

[Blade]

I guess if Allocated is only used at run time, then it reading Count as int32 or int16 would give the same result for the range of values its likely to have, so I can see how it was mis-interpreted.

[Blade]

It looks like the TransFlags array in the footer is an array of boolean values that flags if the blitter should draw index 0 pixels or just skip them and leave the pixel value that was there already for the cells they refer to.