.3 Files

Due to overwhelming demand, I’m starting a thread to summarize the current knowledge of .3 files, and to spur a new thrust for additional insights. The idea is to break down this task into smaller chunks, producing simple tools as necessary.

The .3 files are scripts which tell the game engine how to draw objects. On first glance, they are just binary data. But, after some research, it has been found that the files can be broken down into lines of opcodes which describe how the vertices and polygons go together.

First, we need a tool to take the binary data and reformat it into ASCII text, so it can be edited more easily, then be able to produce a binary file again for testing in the game.

I’ve created an extremely user­unfriendly tool here:
http://rapidshare.com/files/239704747/parse_3.zip

You can put any .3 files you want to process in the 3_in directory. When you press the Convert to Text button, all the files in the directory will be processed and the results placed in the 3txt_out directory. A similar procedure is used to convert back to .3 format again.

Thanks M,

I will look forward to working on this when I dig out from the meltdown that once was my TAW data/test PC. I lost about three years worth of unsalvagable data and am currently reformatting the HDD by necessity. Fortunately I think most of it can be reconstructed from my backup files so please make sure your files are backed up.

Thanks for your continuing work on this project 😎

DKD, hope you get sorted out soon. I need all the help I can get, especially since Polak is absent.

Anyway, if we take one of the simplest examples of a .3 file, one of the F22 control surfaces, f22_30.3and pass it through the parser in verbose mode, we get this:

f22_30.3;
header;FEC03E80000000007FFF00000000000000000000
header;0002000300030000000000000087000700040005
header;00060000000000000020000000200000002000000007
0000;007B0004
0001;0000
0002;00620000000000000000
0003;00750000
0004;00490000E3C0000000000000000000000000000000000004
0005;0000
0006;00620001FEF000000140
0007;0066FFA8
0008;00650007
0009;00680228FE20
0010;0065FFF9
0011;00660050
0012;006100060001
0013;0048000A
0014;002100000016
0015;0021000100AE
0016;002100020146
0017;0021000301DE
0018;0000
0019;0047001D00030000008900B70089000E007B
0020;002F0003000500020006
0021;0047001D000300C5007B000E007B00B70089
0022;002F0003000100060002
0023;0047001D0003000E006B00B7007900000079
0024;002F0003000600030004
0025;0047001D000300B70079000E006B00C5006B
0026;002F0003000300060001
0027;004CBABAC000
0028;0080000500060004
0029;004CC0BABA00
0030;0080000300010002
0031;004EBAC0C0BA
0032;00810005000400030002
0033;0000
0034;0047004500030000008900B70089000E007B
0035;002F0003000500020006
0036;00470045000300C5007B000E007B00B70089
0037;002F0003000100060002
0038;004700450003000E006B00B7007900000079
0039;002F0003000600030004
0040;00470045000300B70079000E006B00C5006B
0041;002F0003000300060001
0042;004CBABAC000
0043;0080000500060004
0044;004CC0BABA00
0045;0080000300010002
0046;004EBAC0C0BA
0047;00810005000400030002
0048;0000
0049;0047000C00030000008900B70089000E007B
0050;002F0003000500020006
0051;0047000C000300C5007B000E007B00B70089
0052;002F0003000100060002
0053;0047000C0003000E006B00B7007900000079
0054;002F0003000600030004
0055;0047000C000300B70079000E006B00C5006B
0056;002F0003000300060001
0057;004CBABAC000
0058;0080000500060004
0059;004CC0BABA00
0060;0080000300010002
0061;004EBAC0C0BA
0062;00810005000400030002
0063;0000
0064;0047002700030000008900B70089000E007B
0065;002F0003000500020006
0066;00470027000300C5007B000E007B00B70089
0067;002F0003000100060002
0068;004700270003000E006B00B7007900000079
0069;002F0003000600030004
0070;00470027000300B70079000E006B00C5006B
0071;002F0003000300060001
0072;004CBABAC000
0073;0080000500060004
0074;004CC0BABA00
0075;0080000300010002
0076;004EBAC0C0BA
0077;00810005000400030002
0078;0000
0079;FFFF
0080;FFFF

The 2nd,3rd and 4th lines can be classed as a header. The header is likely the area where data specific to a particular object is placed during runtime. Other than that, not much is known. The last two bytes (0007) do give the total number of vertices used by the model.

In verbose mode, the parser puts in line numbers which may help with navigating the file.

I have no idea what line numbers 0000 through 0005 do, although the 0049 opcode has something to do with rotation, in this case relating to vertex index 0.

Lines 0006 to 0012 describe the XYZ coordinates of the 6 remaining vertices. The starting point is set with the 0062 opcode on line 0006:

00620001FEF000000140

This can be broken down to the following:

0062=opcode
0001=vertex index=1
FEF0=X coordinate=­272 decimal
0000=Y coordinate=0
0140=Z coordinate=320

The following lines 0007­0011 then give the positions of the subsequent vertices relative to the one before, so for line 0007:

0066FFA8 (FFA8=­88 decimal)

The 0066 operator only gives the Z­axis translation, so that vertex 2 will be positioned at:

X,Y,Z
X=­272,Y=0,Z=320­88=232

Lines 0008 to 0011 are similarly handled according to the following rules for each opcode:

0062 vvvv xxxx yyyy zzzz
0063 xxxx yyyy zzzz
0064 xxxx
0065 yyyy
0066 zzzz
0067 xxxx yyyy
0068 xxxx zzzz
0069 yyyy zzzz

I’m not sure of the exact purpose of line 12:

006100060001

but the 0061 operator gives the number of vertices described in the preceding lines (6) and the starting vertex (1).

Next, comes lines 0013 to 0018:

0048000A
002100000016
0021000100AE
002100020146
0021000301DE
0000

This is a decision block, identified by the 0048 opcode. The decision in this case is based on the value contained in variable 000A. I don’t know where this variable is actually stored, but it is very possibly in the header.

The 0021 opcode can be considered as an = operator followed by a jump.
Thus, 002100000016 can be read as If the value of variable 000A=0 then jump 0016 bytes. The jump distance includes the 0016 itself.

If we count the bytes, this takes us to the start of line 0019.

The other 3 0021 lines take us to the start of lines 0034,0049 and 0064 respectively. The blocks starting at these lines are practically identical to that starting at 0019, which is the only one I’m going to go through in detail.

Finally, we have lines 0019 to 0033 which describe the polygons.
Lines 0019 & 0020 should be treated as a pair:

0047001D00030000008900B70089000E007B
002F0003000500020006

This can be broken down as follows:
0047 This is the opcode for a textured polygon
001D Index number of texture from the file redXXXX.ini in the 3 folder (cam3_7)
0003 Three sided figure, ie triangle
0000 0089 Texture coordinate of vertex 5 (taken from 002F line)
00B7 0089 Texture coordinate of vertex 2
000E 007B Texture coordinate of vertex 6

The texture coordinates are referenced to the top left corner of the texture, with an X coordinate between 0­255dec, and a Y coordinate in the range 0­191dec.

Lines 0021 to 0026 describe 3 more textured polygons.

Then comes 3 shaded polygons in lines 0027 to 0032. The following must be trated as a pair:

004CBABAC000
0080000500060004

The 004C opcode is for shaded triangle, and taken together with the following 0080 line, can be interpreted thus:

Vertex 0005 uses palette colour BA
Vertex 0006 uses palette colour BA
Vertex 0004 uses palette colour C0

In this case,vertices 0005 and 0006 will be the same colour and there should be a smooth gradient across the triangle to the colour at vertex 0004.

The following lines can be treated similarly, noting that the 004E/0081 opcode combination relates to 4 sided polygons.

If we want to create some sort of viewer, the only things we need to worry about are the vertices and one of the 4 sets of polygons, ie the following lines:

00620001FEF000000140
0066FFA8
00650007
00680228FE20
0065FFF9
00660050
0047002700030000008900B70089000E007B002F0003000500020006
00470027000300C5007B000E007B00B70089002F0003000100060002
004700270003000E006B00B7007900000079002F0003000600030004
00470027000300B70079000E006B00C5006B002F0003000300060001
004CBABAC000
0080000500060004
004CC0BABA00
0080000300010002
004EBAC0C0BA
00810005000400030002

A script can then be created to transform these lines into a file that can be read by a 3d modelling program. I use AC3d because it has an ASCII text file format. You don’t need to buy the program if only using it as a viewer, and it can be downloaded here:
http://www.inivis.com/
I’ve uploaded the f22_30.ac example file here:
http://rapidshare.com/files/240108397/f22_30.ac

If all goes well, you should see something like this:

So,to summarize, f22_30.3 produces one of the F22 control surfaces. It contains 4 sets of polygon descriptors differing only with the texture used for the different camouflage schemes.

This is one of the simplest models, but it is by no means totally understood. 🙁

Any questions before we move on? 🙂

mikew

Any questions before we move on? 🙂

Captivating display of knowledge and insight. Most appreciated!
One question on the decision blocks, are they exclusively identified by the 0048 opcode?

The 0048 opcode is used for certain types of decisions. We’ve seen that 0048000A for camo selection. 00480007 is used to select different damage states in other .3 files. I don’t know whether this is a general rule. I guess I should find out.

In some .3 files, the 0027 opcode is used to make decisions based on distance. Also 0043 is used for time of day.

Even more speculative is the theory for the 0015 opcode. This looks like it’s making a decision on whether a polygon’s normal is positive or negative for backface culling purposes ( http://en.wikipedia.org/wiki/Back_face_culling ) . Again, I don’t know whether this is relevant in anything other than software mode since DirectX is supposed to handle that.

After looking at these files for a while, it wouldn’t surprise me if this .3 file system has evolved over many years…even going back to the Amiga days.

mikew

Even more speculative is the theory for the 0015 opcode. This looks like it’s making a decision on whether a polygon’s normal is positive or negative for backface culling purposes . Again, I don’t know whether this is relevant in anything other than software mode since DirectX is supposed to handle that.

After looking at these files for a while, it wouldn’t surprise me if this .3 file system has evolved over many years…even going back to the Amiga days.

Looking at the 0015 opcodes in your A50.3 file, reminds me of the discussions I used to have with Polak regarding a visual phenomenon with the the A50’s in TAW that displayed what I refered to as a ghosting quality. It made the A50’s less visible/detectable in­game. IIRC this was exclusive to the Glide API installations, but I could be mistaken.

As to your statement regarding the evolution of the .3 file system, I would be interested to see if the Typhoon files show any progression?

One more question please?

In an effort to understand more fully, before you move on, I recall your statement regarding Back­face culling and am curious about (nonkrus) file 11253 which is a blue square but only visible from one side:

FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E022C022C022C0000000000000023
00620000FFE2FFEC0000
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
006100230000
00020010000000090001
0071000100090006
0071000100060002
0071000200060007
0071000200070003
0071000300070008
0071000300080004
0071000400080005
00710009000A0006
00710006000A000B
00710006000B0007
00710007000B000C
00710007000C0008
00710008000C000D
00710008000D0005
00710005000D000E
0071000A0013000B
0071000B00130010
0071000B0010000C
0071000C00100011
0071000C0011000D
0071000D00110012
0071000D0012000E
0071000E0012000F
0071001300140010
0071001000140015
0071001000150011
0071001100150016
0071001100160012
0071001200160017
007100120017000F
0071000F00170018
00710014001D0015
00710015001D001A
00710015001A0016
00710016001A001B
00710016001B0017
00710017001B001C
00710017001C0018
00710018001C0019
0071001D001E001A
0071001A001E001F
0071001A001F001B
0071001B001F0020
0071001B0020001C
0071001C00200021
0071001C00210019
0071001900210022
0000
FFFF
002000200020

Any comments would be informative.

Questions are what will make this thread live or die, the more the better. 🙂

I don’t anything about Typhoon since I haven’t managed to extract the files.

That 11253 file is interesting, they don’t come much simpler than that. I don’t have time to analyse it today, but the following line defines the colour (I think):

00020010000000090001

The value in red gives the palette position which should be blue.

A bit more detailed comment on DrKevDog’s example above:

The file describes a vertical blue rectangle made out of 48 triangles, only visible from one side. Which side is shown depends on the order the vertices appear in the polygon descriptors (the lines starting with 0002 and 0071).
If we take the first 0071 line:

0071000100090006

This describes a triangle made up vertices 0001,0009 and 0006. If you could see a pointer which circulates between these vertices in space in this order 1­>9­>6­>1­>9­>6, the pointer would be moving in either a clockwise or anticlockwise direction depending on which side you were looking at.
This is used as a test by the graphics engine to decide whether to show the triangle or not. The opposite side can be displayed instead if the vertices are swapped thus:

0071000100060009

In TAW if both sides need to be seen, then both are described separately, ie:

0071000100090006
0071000100060009

Note that if this line to added to the file above, then there are some bytes in the header which would need to be changed as well to maintain integrity.

If we take the header:

FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E022C022C022C0000000000000023

…and split it up further

FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E
022C
022C
022C
0000000000000023

…and if we count the number of bytes to the end of the file following the last 022C, we find there are 556 decimal or 22C hex. So, for reasons currently unknown, if we add an extra 0071 line, then we have to add 8 to each 022C, giving 0234 hex…or we get a crash.

Bravo, very well done, and you described the process as a skilled educator would communicate: clearly and effectively.

So to summarize, I would say we started with my erroneous statement of a blue square which has now been described as a blue rectangle comprised of 48 triangles with 23 Vertices. The anticlockwise polygon winding convention utilized by the graphics engine to determine the face only shown feature is a destinctly dfferent convention than back­face culling and thank you for that.

The area of some question is in your statement regarding the line which defines the colour: 00020010000000090001

You stated the value in red gives the palette position which should be blue, however, in your previous description of the control surface file, f22_30.3 you described the following:

mikew

Then comes 3 shaded polygons in lines 0027 to 0032. The following must be trated as a pair:

004CBABAC000
0080000500060004

The 004C opcode is for shaded triangle, and taken together with the following 0080 line, can be interpreted thus:

Vertex 0005 uses palette colour BA
Vertex 0006 uses palette colour BA
Vertex 0004 uses palette colour C0

Should not the colour determinants for the rectangle be the conventional analogous pair:

006100230000
00020010000000090001

???

Looking back at Polaks index of palette colors and applying this to the control surface file, vertex 0004­0006 use palette colours BA & C0 which are the correct Plane camo.

I do see how your 16 (Dec) gets us blue for the rectangle (00020010000000090001) and are we then, perhaps, describing a vertex colouring scheme that involves a non­shaded triangle opcode which extends over vertex 0009 and 0001?

As to 006100230000 and the potential for palette colour pairing, 0=Black and 23=Terrain Textures…

The 006100230000 line has something to do with vertex description rather than polygons.

There are various ways that the polygons are defined. Polygons can be 3 or 4 sided, although lines will be included in this category as well.

1. 004C and 0080

Example

004CBEBEB000 The 004c line is always followed by one or more 0080 line:

0080002B00280003
00800028002C0003

This relates to non­textured triangles, and the 004c line gives which palette position will define the colour at each of the 3 vertices. So, using the first 0080 line, vertex 2b will be coloured with the colour at palette position be. Vertex 28 with colour be and vertex 03 with colour b0.
This will result in a triangle with different colour corners, but the colours are somehow blended together as a gradient between the vertices.

2. 004E and 0081

This are the 4 sided version of the above:

Eg

004ED4CCCCD4
008100560052002C0028

3. 0002 and 0071

These relate to triangles of uniform colour. The 0002 line sets the colour and used vertices of the first triangle. If there are more triangles of the same colour needed, the 0071 line is used.

Example:

000200C4004000420039
0071004100400039
00710008003B003A
007100090008003A
000200D0004000390042
0071004100390040
00710008003A003B

Here, the first 0002 line sets the colour at palette position c4 to be used. This colour will be used for the following 0071 triangles, after which the second 0002 line changes the colour to d0.

4. 0003 and 0072

This is the 4 sided equivalent of 0002 and 0071

Example

000300B900210020001D001C
0072001C001D00250026

5. 009F

Example:
3 sided

009F000C0032030100CA00C900CB009D000900020001
00000000____0000____________0000____________
__________T_______C1__C2__C3______V1__V2__V3

(the 0’s are used as filler to try to create some whitespace on this site, although it still doesn’t line up properly 🙁)

This is used for textured polygons, but if the texture is not used, also contains the colours (C1,C2,C3) to be used at the vertices to produce a shaded polygon instead. In the example above, which is taken from tent_3.3, the texture(T) is defined by the number 32h or 50 in decimal notation. Some cross referencing is needed to find out what this means.
In the 3folder there are some .ini files. Here are the relevant parts of red1000.ini

[dir]
TM=red1000
[globaltextures]
1=cam3_9
2=cam3_10
3=plane_21
4=material
5=mattdead
6=mob_5
7=fx_4
.
.
[surface]
.
.
48=txtr 10,(192,128),(223,128),(223,159),(192,159) ;BOT ROCK
49=txtr 10,(224,128),(255,128),(255,159),(224,159) ;TOP ROCK
50=txtr 4,(0,160),(31,160),(31,191),(0,191) ;N CANVAS
51=txtr 4,(32,160),(63,160),(63,191),(32,191) ;NE CANVAS
.
.

In the [surface] section, it can be be seen that 50 corresponds to txtr 4. According to the [globaltextures] section 4=material which finally gives the filename of the texture to use. This is material.tm from the red1000 directory in this case.

The coordinates given in the [surface] section give which part of the texture to use since the texture size is fixed as 256x192. So, in this case the part used is outlined in red.

The 4 sided example is shown here:

009F000E0036040100CA00C900C800C9009E0004000300060005

There is also a simpler version of 009F to be used when it is not required to have separate colours for each vertex if the texture is not used. A single colour is specified instead.

Example:

009F00080038010300CC009E0009000400050008

Here the colour cc is applied to the whole 4 sided polygon if the texture 0038 is not used.

6. 002E and 002F

This is used where specific parts of a texture need to be used. The following example is a 3 sided polygon taken from sea.3:

002E0000000300BF000000880032008F0000
002F0003001800120017

The 002E part gives x any z coordinates to define which part of the texture (the filename of the texture is given in the header of the .3 file) shall be used with the vertices defined in the 002F line. Here, the coordinates are:
Vertex 18, x=bf, z=00
Vertex 12, x=88, z=32
Vertex 17, X=8f, z=0

There is also a 4 sided version of this

7. 0047 and 008E

Example:

00470009000400010020002000200020003F0001003F
008E000400110010000E000D

The 0047 opcode can be treated the same as the 002E opcodes except the texture used is taken from the redseaXXXX.ini file and not that as described in the header. Immediately after the 0049 is the index of the texture used, which in this case 0009. Since the index system starts at 0 in the .3 file, but 1 in the .ini file, we have to add 1 giving (in this case) the texture fx_13.

8. 0001

This is used to draw a line.

In this example:

000100C800420041

A line is to be drawn between vertex 42 and 41 using palette colour C8. Since there is no thickness parameter, it is currently unknown how this system works at different viewing distances.

Well, that’s a lot to digest and I have been trying to review your previous tent posts as well. That will take some time so I’ll see if I’m on the right track.

I was curious about how the models are called with respect to time­of­day/shadows, angle­of­view, etc. The T.O.D of the .ini files answers the first question so is it correct that the angle of view polygon texture is consistent with the directional labels in the txtr file index (N,NE, etc.) ? If so, what is BOT?

50=txtr 4,(0,160),(31,160),(31,191),(0,191) ;N CANVAS
51=txtr 4,(32,160),(63,160),(63,191),(32,191) ;NE CANVAS
52=txtr 4,(64,160),(95,160),(95,191),(64,191) ;E CANVAS
53=txtr 4,(96,160),(127,160),(127,191),(96,191) ;SE CANVAS
54=txtr 4,(128,160),(159,160),(159,191),(128,191) ;S CANVAS
55=txtr 4,(160,160),(191,160),(191,191),(160,191) ;SW CANVAS
56=txtr 4,(192,160),(223,160),(223,191),(192,191) ;W CANVAS
57=txtr 4,(224,160),(255,160),(255,191),(224,191) ;NW CANVAS
58=txtr 10,(192,160),(223,160),(223,191),(192,191) ;BOT CANVAS
59=txtr 10,(224,160),(255,160),(255,191),(224,191) ;TOP CANVAS

009F000E0035040100D000D000CD00CD009E0001000000040009
009F000E0033040100CE00CE00CF00CF009E0000000100020003
009F000C0036030100CA00CB00C9009D000400000003
009F000C0032030100CA00C900CB009D000900020001
009F000E0036040100CA00C900C800C9009E0004000300060005
009F000E0032040100C900CA00C900C8009E0002000900080007
009F000E0038040100CC00CC00CA00CA009E0009000400050008
009F000E0034040100C800C800C600C6009E0003000200070006

The eight polygons use only SE, NE, S, N, W, and E, is that as a function of the simplicity of this particular tent3.3 model?

As to the determination of whether a polygon receives texture or not, what is the switch…ie., is it determined by the TAW OPTIONS selected or are there other determinants?

Since we’re on the subject of textures, I have been curious to see if I could understand the transitional textures better. You describe, very well, how the textures for the above 3 files are determined. Have you any insight as to how the transitional textures are utilized? I was hoping to see if it was possible (or advantageous) to make the transiton from the default:

[transtxtr]
A=(0,0)
B=(95,0)
C=(191,0)
D=(0,95)
E=(95,95)
F=(191,95)
G=(0,191)
H=(95,191)
I=(191,191)

To the expanded list from the extracted hardware.tm file:

[transtxtr]
A=(0,0)
B=(95,0)
C=(95,95)
D=(0,95)
E=(96,0)
F=(191,0)
G=(191,95)
H=(96,95)
I=(0,96)
J=(95,96)
K=(95,191)
L=(0,191)
M=(96,96)
N=(191,96)
O=(191,191)
P=(96,191)

🙂

All I know about shadows is contained in another thread from this post onwards:
http://simhq.com/forum/ubbthreads.php/topics/2455256/Re_New_topic_for_reopen_3_form.html#Post2455256

I don’t think the comments N CANVAS etc serve any practical purpose since objects can be rotated based on a parameter given in the ssd file:
http://simhq.com/forum/ubbthreads.php/topics/2124630/Re_Luxor_ssd_and_its_3_files.html#Post2124630
So, N CANVAS may not always be facing north.

DrKevDog

As to the determination of whether a polygon receives texture or not, what is the switch…ie., is it determined by the TAW OPTIONS selected or are there other determinants?

I think it’s just TAW OPTIONS since the LOD based on distance is handled in a different way.

As for the [transtxtr] stuff, I have no idea…or have forgotten. We really miss Polak for this.
The only comment I can make is that these describe 96x96 squares which are used for the terrain.

Okay, thanks for the references. I’ll work on the transtxtr stuff over time and report what I find.

Your speculative theory of the elusive 0015 opcode caught my attention. previously you refered to your noticing that the extra non­visible vertices you found in the terrain tiles were somehow linked to some of the visible vertices and were described by the following lines:

0015001a0003000d000c
00080192
000801ce
0000
000801c8
00080184
0000

I have a theory but I’m not able to confirm nor deny it yet, but here it goes…

TAW extracted Noname file 3158 is the 3D file for the AGM86 Air launched cruise missile.
TAW extracted Noname file 802 is the 3D file for the Air launched Decoy.

Both files describe a functional set of wings which are only deployed/visible at specific conditons met (eg: launch) [Decision opcode?] [back­face culling?]

3158 has 12 such blocks and 802 has 9. Could these be the description of the extra vertices for the extended wings when deployed?

Eg: (noname3158)

0015001000050013000C
000800E4
00080086
0000
00080080
000800D6
0000

Let’s take noname3158.3. After converting to text I ran the file through my rudimentary .3 to .ac formatting program. This was quite successful since the vertices, in this case, are described in one contigious block. All decisions are ignored, and the program converts all polygons it recognises:

So, we can see that there are two positions the wings can be in, and presumably a third stowed position where nothing is drawn.

Looking at the file, there is a likely looking decision block:

00480000
0021000000C4
002100010064
002200010004
0000

From the 0048 line, we are dealing with variable 0000. The value of this must be set elsewhere,but my theory is that it is placed in a defined place of the .3 file header at runtime so the subsequent code knows where to find it.

Anyway, if the value of this variable is zero, then we jump 00C4 bytes, if 1 then the jump is 0064 bytes, and anything greater than 1 gives a jump of 0004 bytes. This last case takes us to the line immediately following the decision block. Note that the jump distance includes the 2 bytes which give the distance.

If these jumps are followed to their destinations, it can be seen that they all point to 0015 lines:

0015000400090003000C
000800E4
0008000E
0000
00080008
000800D6
0000

I’m still not sure what these do, but it could be either for backface culling or z­buffering purposes…or something else, of course. Either way, they define the order in which the polygons are sent to the screen.

I interpret the 0015 line as:
Perform test on vertices 0004,0009,0003. If TRUE then GOTO next line. If FALSE then jump 000C bytes.
If the result was TRUE then we are at the line 000800E4, which I interpret as a GOSUB to the polygon block 00E4 bytes distant. When returning from this sub, the line 0008000E is executed which takes us to the line following this block,which is another 0015 line.

If the result was FALSE then, using this logic, we handle the next 0015 block before coming back to execute the 000800D6 line and this is where I gave up trying to follow the thread of execution. I still haven’t got to grips with how these files.branch. 🙁
All help gratefully received…

There are some further decisions based on distance, performed by 0027 lines, ie

0027000A0122
004E70707E7E
0081001900180010002D
…etc

or

0003007B001900180010002D
…etc

This means that if the viewing distance is less than 000A units (about 80 feet I think) then the polygon with vertices 0019,0018,0010,002D is a polygon with a colour gradient given by the 004E line. ie the polygon corner colours are 70,70,7E,7E respectively. These numbers represent the palette index.
At a distance of greater then 000A units, a uniformlly coloured polygon is used instead with colour 7B as defined in the 0003 line.

mikew

…We really miss Polak for this…

I agree 100%. I did receive an Netlog related email from him recently but it was difficult to understand and I’m not sure what his TAW retur�…
see just how much amazing progress you’ve made since he left, he’ll re­engage. My current job responsibilities and time constraints won’t �…
the next couple weeks 🙁 but I’ll keep plugging away.

I’m not sure that much progress has been made, but it’s been useful for me to try and document things. Maybe we should investigate Homr�…
wiki. Certainly this guy’s efforts for F15SE3 put me to shame:
http://simhq.com/forum/ubbthreads.php/topics/2740370/F_15_Strike_Eagle_III_editing_.html#Post2740370

Anyway, off to the arctic for a few days. No internet, but will try to work on TAW, since with perpetual daylight I won’t be getting much sleer�…

Continuing the theme of gradual progress, I’ve produced a tool 3text_to_ac which takes the text output file of parse_3 attempts to produc�…
based on the current understanding of how the .3 file is constructed.
Here’s the link:
http://rapidshare.com/files/252196488/3_to_ac.zip

Unzip the file to a new directory, then place any *.3.txt files created with parse_3 (Don’t use verbose mode) into the 3text_in folder. Then�…
try and convert any file it finds. The output .ac files will be found in the ac_out folder. Unfortunately, this folder also contains the texture fil�…
Win Explorer will bring these files to the top.

Note, that this program will convert any vertex and polygon info that it understands and pays no attention to LODs, damage etc. So, everyt�…
this A50 example.

There is an interim tool required between parse_3 and 3text_to_ac which sorts through the way the .3 file branches, so that only the rele�…
converted. I’m looking into this now.

Mikew,

Thanks for the program 👍

Just an FYI, I thought I would tinker with the affect of altering object colors in TAW so I took the Decoy file (fzdecoy.3) and converted the d�…
red for better visual tracking. So I modified:

0258;000200B40001001E001F

to

0258;000200090001001E001F

That worked beautifully, during the daytime T.O.D.’s and especially well at night as the bright red polygons are easily visible. The problem �…
Vision Equipment) is toggled ON. At that point the polygons are rendered transparent. I’m assuming that is a function of the Palette tran�…
at position 180 (09h). Your thoughts?

DKD,

If you look at the rest of the natural light palettes, you will notice the same library of bright colors in the first row and a half. These are use�…
lights, runway/taxiway lights, and basically any color that involves artificial illumination. As you well know, position 9 is a bright red.

Compare these palettes with the NVG palette, and all of a sudden you no longer have the same colors, but a slew of blacks and greens. P�…
is a fairly neutral green, and may not show up when seen surrounded by other greens on the 3 object.

FWIW, there is no transparent color, except for what is defined by what color at what time/position (you can see the chroma keying sch�…
files). That said, the 0,0,0 black is often used as a transparency.

This may not be exactly what you’re looking for, but it’s my $.02 anyway.

HomeFries,

Thanks for the input. I believe you probably know much about the NVG Palettes so that info is helpful. I don’t, however, think it was green �…
get a brief update on how transparencies are rendered, especially WRT code identifications. I’m going to be away from the computer for a f�…
my return.

DKD,

Interestingly enough, Eagle Flight found this during beta testing of some new skins. The screenshots were done in Direct3D in 1024x768. The skin i�…
the YF­22 paint scheme.

There’s not even illumination of a neutral green color. You may be on to something here.

Mikew,

Going back and reviewing the previous information on the board regarding the default newhoriz.3 vs the extracted version with its additional �…
In AC3D they look identical, however, looking at the code reveals the differences. The files diverge at line 0491 where the new file has:

0491;00A30090
0492;000300800013000000030012
0493;00720012000300040011
0494;00720011000400070014
0495;007200000009000F0003
0496;00720003000F00100004
0497;00720004001000080007
0498;0072000900160017000F
0499;0072000F001700180010…

The 00A3 opcode appears to be an operator associated with a jump. If you jump 0090h you are at the start of the additional lines not foun�…

In a previous thread discussing the 3 files you mentioned that:

Regarding the Header, it sounds like good progress has been made by breaking them down into 5 categories. It would be interesting to k�…
files have the 00A3 tag with no exceptions.

I believe you are correct that the 00A3 opcode, which is found in the Header of many terrain files, is related to a fairly global TAW process �…
could be used for certain types of decisions such as AGP vs Standard texture mapping, for example. If you recall my earlier discussions r�…
and the implementation of the new AGP "SKY" .RAW files,

http://simhq.com/forum/ubbthreads.php/topics/2605948/2.html

I proposed that the additional lines in the new file would accomodate the implementation of the AGP set.

To follow this logic further and if my use of your extremely insightful guide to the interpretation of the .3 files is accurate, I could start with t�…

0508;0047014200040000000001FF000001FF000100000001
0509;002F00040012001300000003

0047 This is the opcode for a textured polygon
0142 Index number of texture from the file redXXXX.ini in the 3 folder (322d). 322 is not in the TAW default .ini file series but is added man�…
AGP .raw file related lines:

322=sky0800
323=sky1000
324=sky1200
325=sky1400
326=sky1600
327=sky1800
328=sky2000
329=sky2200
310=sky0000
311=skynvg

0004 Special 4 sided Polygon?
0000 0000 Texture coordinates of vertex 12
01FF 0000 Texture coordinate of vertex 13
01FF 0001 Texture coordinate of vertex 0
0000 0001 Texture coordinate of vertex 3

etc..?

This maps the raw textures onto the newhoriz.3 grid when AGP is active using the 00A3 operator. (?)

HomeFries

There’s not even illumination of a neutral green color. You may be on to something here.

I agree, it’s a very curious finding, perhaps we can explore it further?

Interesting! That 00A3 opcode is quite rare and I haven’t yet tried to guess what it does, but your theory seems sound. So, we can say for �…
If AGP (or something else) is enabled then jump 90 bytes

I’m not sure the 00A3 in the headers is linked to the 00A3 opcode, but will keep it in mind.

As to the textured polygons, I suggest you make some changes and see what happens. The AC3D converter is still very crude and will no�…
doesn’t understand.

In your example of a 0047 line, you’ve got texture coordinates for a rectangle of size 512x2. This doesn’t fit in with normal textures, which �…
but of course the textures in the agp folder can be handled differently. I haven’t looked into this before.

The textures sky0800 etc, I assume you’ve found among the nonames?

yes, I found all the 384kb textures (SKY0800­2200). Still searching for SKY0000 and SKYNVG which are other than 384kb’s. The AGP sky texture appears coarse in the game and yet I’m fairly certain It is partly a function of the fact that I do not have all the variables ironed out.

I tried a quick manipulation of the textures in TAW by altering the .ini file. When I subed Material at position 322 I get a ERROR :

Unable to find .\agp\material.raw.
version 5.191 by on Nov 16 1998.

When I sub flare1.raw, a 16kb .raw file, I get:

ERROR : File .\agp\flare1.raw size does not match expectated size.

Substituting the SKY1000 for SKY0800 at the 322 position I get:

fadetab: invalid fade table 12

so the fade tables must be compatible or TAW crashes.

If my figures are correct, the 12 textured rectangles described in the expanded newhoriz.3 file are roughly: 512x2(3), 512x150(3), 512x50(3) and 512x55(3).

Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?)

DrKevDog

Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?)

Doesn’t seem to be, but you could just put the appropriate skyXXXX.raw file in slot 322 for each of the corresponding redXXXX.ini files.

I had a look at some of those 384kb files and they definitely look like sky, when opened as 24 bit colour with size 512x256. If zoomed in, the colour gradient isn’t smooth, which is maybe why it looks course in the game.

DKD, you’ve made a great find here. 🙂

mikew

DrKevDog

Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?)

Doesn’t seem to be, but you could just put the appropriate skyXXXX.raw file in slot 322 for each of the corresponding redXXXX.ini files.

I had a look at some of those 384kb files and they definitely look like sky, when opened as 24 bit colour with size 512x256. If zoomed in, the colour gradient isn’t smooth, which is maybe why it looks course in the game.

Mikew,

I am grateful for the knowledge you share regarding this project, it makes this TAW puzzle more fun to discover 🙂

I don’t believe I have the SKY.raw files exactly matched up with their correct T.O.D. in the AGP folder so some of the sky textures don’t match the horizon band of color… that said, I do get different sky textures based on the T.O.D. so I am wondering, since there is only one newhoriz.3 file with only 322 position references, if there is an algorithm (somewhere in the process) that selects for the correct redXXXX.ini index position?

I tried substituting the SKY1000.raw for SKY0800.raw at the 322 position I get: fadetab: invalid fade table 12. Apparently the fade tables must be compatible with the Sky texture used or TAW crashes. IIRC the fade tables are related to the sky as visualized in the AWACS 3D window. I did find a number of unused noname fade tables in the Multiex extracted files.

Thanks for posting the pics of the raw files, for some reason my photoshop and irfanview pics were less well defined.

I did some comparison last night with the AGP­sky at 2200 vs the non­AGP­sky on my PCI/Glide PC and the textured sky at night is far superior 👍

mikew

Doesn’t seem to be, but you could just put the appropriate skyXXXX.raw file in slot 322 for each of the corresponding redXXXX.ini files.

I am not sure I communicated my point on the T.O.D. issue very well, so I’ll try expanding it. The information that motivated me to consider the utilization of .ini positions 322­329 was obtained from a noname .ini type file that begins with:

[dir]
TM=hardware.tm

tha section of current interest is listed:

322=sky0800
323=sky1000
324=sky1200
325=sky1400
326=sky1600
327=sky1800
328=sky2000
329=sky2200
310=sky0000
311=skynvg

What you say regarding the lone 322 position seems logical, and I’ll plan to do some further testing this evening, however, I am interested in finding out if the above .ini file is a clue to how the AGP­SKY textures are used in general or if their is seperate special TAW application which utilizes only the above .ini file

I’m sure it was me that misunderstood, but I can’t see a mechanism to change TOD in the newhoriz.3 file…even the one you found.

There may be a way around this though. For the building .3 files, there is a decision point based on TOD which is used to draw the shadows. It may be possible to use the same process to select different skyXXXX.raw files.

I really need to get the textured sky working on my machine, as I am still not sure what is going on here. Is it really possible to use textures of 512x256 and colours which are not from a palette???? Sounds too good to be true. 🙂

Gents,

This might be something huge. Being that hexidecimal is not my strength (too long looking at it and my head explodes), I apologize if I ask questions that may have already been answered.

1) Are you saying that the skyxxxx gradients are actually being used in extracted TAW (D3D renderer), or that files are called which are still unnamed (which explains the coarse gradient)?

2) If the gradients are in use in D3D, I understand that they must be matched to the palette. Does this mean they also must be matched to the time of day? (a way to find out might be to swap the names of two palettes, then swap the names of sky files or swap addressses of sky files in the noname.ini)?

Just thinking out loud, this discovery might be the key to fix my NVG mod in D3D by swapping the rednvg and redmoon/rednomo palettes without having to deal with the green gradient that isn’t swapped. See this thread for further details.

HF, I’m having problems understanding what’s going on as well. 🙂

I thought I’d take it step by step and just swap the original newhoriz.3 file with the one DKD found. I was expecting a crash but instead, the game ran as normal.
The particular PC I tried this on has a hardware problem in that even though an AGP graphics card is fitted, the AGP capability is not recognised by the video driver or DirectX. So, this may prove that the 00A3 opcode is related to AGP since then the newhoriz.3 code will select the coloured polygons instead.

DKD, is this a correct assumption?

Mike,

Feel free to send me any files. I can test them on an agp platform.

mikew

HF, I’m having problems understanding what’s going on as well. 🙂

I thought I’d take it step by step and just swap the original newhoriz.3 file with the one DKD found. I was expecting a crash but instead, the game ran as normal.
The particular PC I tried this on has a hardware problem in that even though an AGP graphics card is fitted, the AGP capability is not recognised by the video driver or DirectX. So, this may prove that the 00A3 opcode is related to AGP since then the newhoriz.3 code will select the coloured polygons instead.

DKD, is this a correct assumption?

Yes, that is the working hypothesis. I believe opcode 00A3 is related to AGP. Over the years I have modified many aspects of my TAW files and so there are many potential confounding variables in this equation, that said, I am now in the process of reinstalling and rebuilding TAW from it’s default configuration and adding the extracted components, progressively and incrementally until the AGP Sky appears. Hopefully I can get a read on how this is implemented.
I should be back with some results momentarily.

I believe the series of tests confirm my hypothesis and the results are reproducable. I started with a new TAW install, converted it to a virgin extracted files program and added components until I arrived at the point of viewing a non­palette derived textured sky.

The necessary components are:

1. AGP Graphics card/ Extracted TAW running in hardware mode
2. Collection of 384kb SKYXXXX.raw textures placed in the AGP directory
3. The extracted noname newhoriz.3 with expanded AGP code
4. modified redXXXX.ini files to include:

   322=sky0800
   323=sky1000
   324=sky1200
   325=sky1400
   326=sky1600
   327=sky1800
   328=sky2000
   329=sky2200
   ;310=sky0000
   ;311=skynvg

One of the curious observances on this trial was the fact that placing only the 322=SKYXXXX line, as opposed to the entire block, in the redXXXX.ini file resulted in the entire sky (minus the lower horizon band) being black

DKD,

Is there any reason skynvg is remmed out?

HomeFries

DKD,

Is there any reason skynvg is remmed out?

HF,

The reason is we have yet to find that file or the Sky0000.raw file. What I do know about them is they are not 384kb files like the other Sky .raws. Since you are on the NVG subject, there is a NVG file in TAW that is analogous to the newhoriz.3 file for the standard sky projection. It is nvg_hori.3 and there are more than one, one of which was a noname file and not used in the game. A quick look at the code structure seems to suggest some polygon and color differences which may be of some benefit in your search for a NVG solution. The file is TAW noname11364.

It does appear that the 00A3 opcode is a decision point for AGP, but exactly how it obtains that determination is unclear to me at this time. I would really like to get these textures running on one of your PC’s, so what do I need to send to you? . Mikew, on your PC with the AGP card, do you get colored missile trails, etc. in TAW? Do you have an AGP folder/files? HF, do you have an AGP folder with .raw files?

HomeFries

2) If the gradients are in use in D3D, I understand that they must be matched to the palette. Does this mean they also must be matched to the time of day? (a way to find out might be to swap the names of two palettes, then swap the names of sky files or swap addressses of sky files in the noname.ini)?

Interestingly enough, the textured sky is not at all effected by the color palettes. The color palettes do greatly effect the sky color of the standard polygon colored sky but have but appear to not be associated with the .raw files rendering. The time of day match is a little tricky. If you look at mikews post of the 384kb files, you’ll see that the T.O.D. name designation could be guessed at, which is what I have done 😉 until a more accurate method is found.
I am curious to know what methods (eg: layering, etc.) could be used to effect the textured sky appearance.

DKD,

Here’s the genesis of my questions:

1) You might be aware that the gist of the NVG mod is to swap the nvgpal.col and the moonpal/nomopal.col files so that a night mission starts with NVGs on by default (in essence, tricking TAW). This allows for the NVG palette when using LANTIRN at night, which enables a tool that is otherwise useless (especially in the nomo palette).

2) Problem is with D3D mode. When selecting the natural light palette (which TAW thinks is actually enabling NVGs), a boatload of green hues are present in a number of cases. These cases include the horizon gradient, the HUD, the lighting (afterburners and nosewheel lighting as examples), the canopy arrows, and various 3D objects in the game (such as hangars).

What I would really like to see is if swapping sky2200 with skynvg (or just all black since skynvg is unlocated) will help alleviate this issue. I’m not as concerned with dropping skynvg into moonpal/nomopal (in the mod NVGs look fine without a nighttime gradient) as I am about dropping sky2200 into the skynvg position.

If you can send me the files, I’ll be happy to test it myself.

Thanks.

DrKevDog

It does appear that the 00A3 opcode is a decision point for AGP, but exactly how it obtains that determination is unclear to me at this time. I would really like to get these textures running on one of your PC’s, so what do I need to send to you? . Mikew, on your PC with the AGP card, do you get colored missile trails, etc. in TAW? Do you have an AGP folder/files? HF, do you have an AGP folder with .raw files?

The AGP capability is read from Windows, so a flag will be be set when the game starts.
The only reason I have an AGP folder is that it was part of a certain package. This explains why some people who ran Krus’s original extractor in 2006 got an AGP folder and some didn’t. If the PC wasn’t deemed AGP capable, then those files weren’t used. I have a couple more computers that I can try it on, but it won’t be today.

HomeFries

What I would really like to see is if swapping sky2200 with skynvg (or just all black since skynvg is unlocated) will help alleviate this issue. I’m not as concerned with dropping skynvg into moonpal/nomopal (in the mod NVGs look fine without a nighttime gradient) as I am about dropping sky2200 into the skynvg position.

If you can send me the files, I’ll be happy to test it myself.

I’ll send you the files and you can go from there. Just an FYI about your swapping files, the .raw files and the .col files are not interchangable. There is a flag for file size which generates an error message regarding the issue of the file size does not match expectated size.

Understood. just intend to pair the raw with the col files.

Well, I had no luck with my experiment.

I copied sky2200.raw to skynvg.raw, then unremmed the skynvg line in redmoon and rednomo.ini. Got the infamous unexpected file size error. Strange, considering all the other gradient raw files are 384k.

Now I’m interested to see how big the noname1317 file is.

My apologies for leading this thread off topic. If you don’t mind I’m going to move this discussion to your New NVG Patch thread.

Thanks.

no prob.

mikew

The AGP capability is read from Windows, so a flag will be be set when the game starts.

Just a quick note on the 00 A3 Opcode. If you look at the file dust.3 you will find the following:

header;FFFC3E80000000007FFF00000000000000000000
header;0002000300030000000000000083000700040005
header;000600000000000000200000002000000020000000040030001E
0000;007B0004
0001;0000
0002;00080008
0003;0008056A
0004;0000
0005;00A30D16
0006;002700320334
0007;00480000
>>>>>
0238;0000
0239;0001000200030000
0240;00A30338
0241;004B00030004
0242;0000

Could this be a jump to the second 00 A3 opcode?

I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC:

header;FFFC05DC000000007FFF00000000000000000000
header;0002000300030000000000000083000700040005
header;000600000000000000200000002000000020000000040030001E

ie, 8000 vs 16000, maximum visible distance? D3D half that in 3DFx/Glide ?

There are some interesting findings in this file.

0372;00A700A200910075
0373;00470101000400000000008000000080008000000080
0374;008800040000000100020003
0375;00A8
0376;0000

Considering the opcodes 00 A3, 00 A7 and 00 A8, it appears as if their is a seperate set of Opcodes for specific AGP file system.

I modified the dust.3 files code related to the 00 A7 opcodes: 00A700A200910075
Simply changing the color determinant from 00A2 to 0103 changed the texture color for dust.raw from gold/brown to bright green. In TAW the dust plumes from ground vehicles are now visible as green dust, this is the same code in the .3 files responsible for the colored missile trails, explosions, etc.. I ported the modified dust.3 file to my 3DFx­Glide/PCI PC and the AGP opcodes are not recognized, the dust plumes appear as white 3d objects complete with ground shadows which are not present with the AGP/.raw textures system implementation. It is not yet clear what the 008A opcode does however it could be the AGP system equivalent of 00 00 used to terminate the AGP related blocks of code. The AGP flag determines which block is utilized?

00470101… calls 257h + 1; 258=dust (.raw)

DrKevDog

If you look at the file dust.3 you will find the following:

Typical! you pick one of the most complicated files. 🙂
The dust and smoke files were some of the hardest to make sense of when trying to find out how to split them up into opcode lines, and they haven’t necessarily been converted correctly.
Line 0239 is a bit suspicious:

0239;0001000200030000

This is the opcode for drawing a line, but seems out of place here, particularly with its following parameters. So, the chances are I’ve misinterpreted something a few lines earlier.
I’ll try and look at this later and update the Parse_3 program if necessary.

DrKevDog

I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC:

Did you run run Krus’s extractor on both machines? This is worrying if different 3 files are produced on different machines.

DrKevDog

The AGP flag determines which block is utilized?

Seems to be for 00A3. If you go into TAW options, there are buttons for a whole bunch of things like building textures, aircraft shadows etc. It would seem logical that there are opcode combinations to handle these settings.

DrKevDog

00470101… calls 257h + 1; 258=dust (.raw)

At least that stacks up. 🙂

The colour stuff is interesting, but 0102 is not a palette colour since the size of the palette is only 00FF bytes. It may wrap round to 0002 though.
Maybe those lines could be interpreted instead as:

00A7
00A200910075
.
.
00A8

Anyway, a thought provoking post, DKD. 🙂

DrKevDog

I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC:

Now, this is really bugging me. I think we need to find a copy of Krus’s first version of the extractor, ie the one where you had to play the game, in order to ensure (or otherwise) that the .3 files output are the same if different graphics options are selected in TAW Options.

mikew

Typical! you pick one of the most complicated files. 🙂

That’s what friends are for 🙂 sue me 🏋️

mikew

Did you run run Krus’s extractor on both machines? This is worrying if different 3 files are produced on different machines.

It’s been a couple years since I did the most recent extractions and I had to reconstruct my entire Glide/PCI system after a recent meltdown. IIRC the program files on the Glide/PCI PC were ported over from the same extraction used on the D3D/AGP PC, but I’ll have to confirm that.

I’ve just run dust.3 through the parser and there seems to be a 003E opcode that I haven’t identified before:

0135;003E
0136;0000
0137;00B0
0138;0000
0139;0001000200030000

…which should probably be treated as one line, with maybe a terminating 0000:

003E000000B00000000100020003
0000

The 0000000100020003 are probably vertex indices (since this block follows vertex descriptions), but I have no clue as to the rest.

mikew

The colour stuff is interesting, but 0102 is not a palette colour since the size of the palette is only 00FF bytes. It may wrap round to 0002 though.
Maybe those lines could be interpreted instead as:

00A7
00A200910075
.
.
00A8

I have identified basic colors, green and what I would consider 2 shades of red, could the .raw textures palette be limited to 4bit color?

Haven’t been able to crack the 00A7 color code yet, busy chasing my tail on the [Loadsetupsupershape] project. Was able to harvest a list of the 00A7 codes from the heavenly.3 file and a number of the weapons files.

The code lines were hex edited into the dust.3 file and the color of the dust plume in the game was noted:

00A700FB009700FF: Pink/White
00A700FF00BF00D3: Pink
00A700FF00DB00C3: Pink/Amber
00A700FF00E300D7: Light Amber
00A700FF00EF00EB: Amber
00A700FF00DF0093: Gold
00A700FF00CF0053: Bright Gold
00A700FF00CD0049: Yellow Gold

00A700FF00970017: Bright Orange

00A700D600AF0051: Bright Yellow/Gold

00A700C100790031: Orange

00A7009B00600020: Orange/Gold

00A700A7003E002F: Orange/Pink

00A7009300DE00FF: Pink

00A7003900EB006B: Lime Green

00A700BD00390028: Red

00A70078001F0018: Bright Red

If we take the 00A7 line eg:
00A700FB009700FF
and then treat the 3 numbers after the 00A7 as RGB colours, so R=00FB, G=0097 and B=00FF, then repeat for all 17 of the examples above…we get this:

Apart from the 4th to last, the colours come out pretty much as DKD describes. 🙂
…and you can also see that I can’t count.

Okay, very good. So, if I contrast this with the sea.3 files process of color acquisition, is it correct to say the sea.3 calls the Tex4.tm texture map which contains an index to the first 16 positions in the palette (.col) file which determine the color of the .TM texture by using the TAW 6 bit RGB hex codes contained within the .col palette file?
In contrast, the dust.3 file, on an AGP activated PC, will determine the color of its (dust).RAW texture using the TAW 6 bit RGB hex codes directly from the .3 file itself?