Basically correct, except that it's the 16 positions of the palette starting at position 129.

I haven't had time to go into the dust file in any detail, but those 00A7 lines seem to give a direct reference to full 8 bit colour, although stored as 16 bit numbers.
Note also that the skyXXXX.raw files seem to contain 8 bit colour information directly, rather than refer to a palette.

These are some great findings that you are coming up with. Just wish I had more time to help.

Mikew,

Thanks for clearing up those misconceptions for me,...me having misconceptions...that has never ever happened before
Well, I can certainly say I am enjoying these new findings and I have a few ideas about how we will parlay these little niblets into a "LOMAC-ON-STEROIDS" look for TAW

The fact that the sky raws are handled differently than the palette colored sky has got me thinking... perhaps this is a portal of opprtunity that could pay some weather dividends. One of my initial thoughts was the possible use of the NVDOT.raw and/or NVNOISE.raw, which create light dot "artifacts" in the NVG environment, features to create a rain-like effect in the environment. So far I'm starting to be convinced that the NVDOT and NVNOISE files use is hardcoded in the game, so I'll continue investigating this

DKD,

A little off topic from 3 files, but since you're discussing weather, I discovered the following the other night.

In the different time of day text files (\lev\redxxxx.txt), the section that calls the palettes also assigns an altitude range to the palettes. This allows for separate palettes for different altitude bands. Any overlap in altitude bands results in transitional merging of the palettes. I haven't played around with this much in D3D, but done correctly it looks amazing in Glide.

For proof of concept, we could use the greyscale palette in TAW for low altitudes (say up to 5000), followed by the palettes for that time of day (perhaps starting at 1500 up to whatever) to create the impression of a fog/cloud layer that you finally burn through at 5000ft. Only problem is that you would be able to see the ground plain as day above 5k, but that's a topic for another pursuit.

Just throwing my $.02 into the mix.

...Interesting idea.

Just going back to dust.3 for a moment, and these lines:
0372;00A700A200910075
0373;00470101000400000000008000000080008000000080
0374;008800040000000100020003
0375;00A8

There are only 4 vertices in the dust.3 file, so the dust effect must always be somehow billboarded towards the viewer. Line 0372 gives the dust colour. Line 0373 calls the 128x128 'texture' dust.raw which, since line 0374 starts with 0088, is used as a transparency mask.

HF,

I think it would be worth a look see, if you have the time. IIRC I worked on a similar approach before (Glide) and I couldn't get the altitude transitions to work smoothly enough (read: convincingly enough) with the Palettes I had at the time (and I was also concurrently using the East-West Palette system). I remember Polak had some success with creating or modifying palettes so perhaps that is the way to go.

DKD,

Apologies for my ignorance, but what is the East-West palette system? I am not familiar with that nomenclature.

So far as modifying palettes, I have some (albeit limited) experience with this. However, I have taken existing palettes (such as my "new" NVG palette) and adjusted the color/brightness on a consistent basis among rows to make the transition look normal. I will post a video of the transition with NVGs shortly (i.e. once I make it).

Like I said previously, the downside of manufacturing cloud cover like this is that you will be able to see the ground as normal once you clear the grey. However, it should be doable if you make a hybrid palette (i.e. mix greyscale ground textures with normal sky textures as a medium layer), then have the hybrid palette go to a solid grey or more lower contrast grey palette for higher altitudes.

Not as easy as it sounds, but very doable.

Edit: well, maybe it could be easier. Are there utilities that can make global changes (i.e. to luminosity or color) to indexed palettes, and is there a utility that can convert an indexed palette in a graphics file to a .col file? If so, this would really open things up (and not just for weather mods).

You know, it is so fascinating to learn about this process. I am amazed at the images of dust.3 created in AC3D with, if I understand this correctly, two standard TAW texture maps used, one for the XY(exp_6) plane and another for the XZ(exp_1). I was unable to find a AC3D .raw plugin, is there a way to get AC3D to use the raw textures?

Okay I'm trying to understand why when I converted line 0372;00A700A200910075 by changing it to 0372;00A7000000000000 the ground vehicle is seen with a series of progressively enlarging rectangular plates of the exact raw image you posted, without color and trailing the ground vehicle. Almost as if I had lost the dust image and had only the mask, does that seem logical?

Not sure the billboarding orientation is related to this but perhaps the orientation of the 3D image can also be modified by the SSD files using the parameters in the smoke.dat file , eg:

DEFSMOKE "MEDIUMDUST8" ; dust trail
VIS 1000
VEL 0,0,0 ; initial velocity (m/sec)
SPUTTER 0.2,0,0.2 ; random sputtering (m/sec)
LIFE 1.5 ; particle life expectancy (secs)
LIFERAND 0.2 ; random life variation (secs)
RATE 0.3 ; delay between particle emissions (secs)
RATERAND 0.01 ; random emmision variation (secs)
BETWEENS 0 ; How many particles to insert for each particle emitted
VARIABLEBETWEENS 1
UNTIL 1.6 "DT1"
UNTIL 1.2 "DT3"
UNTIL 0.8 "DT5"
UNTIL 0.4 "DT7"
UNTIL 0.0 "DT9"
ROTATE 0
ENDSMOKE

???

The East-West Palette feature was, we believe, a DID method of simulating real world differences in solar influence on sunrise and sunset in TAW although it was never implemented within the game. I was only able to get it functioning in Glide and not D3D. It is fairly easy to set up and the SimHQ thread reference which explains it all is below:

http://simhq.com/forum/ubbthreads.php/topics/2525857/1.html


As to the utility for making global changes to indexed palettes, I'll have to defer to someone more experienced than me

Okay, trying to keep up here...

When you say only 4 vertices:

*00620000FFC700000039
*00640072
*0066FF8E
*0064FF8E
006100040000
0098FFEC

Did you figure out how 0061 functions?

Your visual explanation of the use of the .raw file as a transparency mask is very well done. I noticed the file was 128 x 128 RGB with the alpha channel utilized. It reminds me of the TAW_OPTS.cfg file which has "ALPHA" settings, I just have not been able to figure that file out yet.

My earlier comment about the two TM files used in the AD3C rendering of the dust.3 file, is one related to software mode (exp_1) and the other D3D hardware mode(exp_6)?

0047002A0004005E002F008D002F008D005E005E005E008800040000000100020003...exp_1 at position 43

004700380004005E008D008D008D008D00BC005E00BC008800040000000100020003...exp_6 at position
57

00470101000400000000008000000080008000000080008800040000000100020003...dust.raw at position 258
?

Yes, there are any 4 vertices describing a rectangle. That I'm totally sure of.

00620000FFC700000039
00640072
0066FF8E
0064FF8E
006100040000

A block of vertex descriptions always starts with a 0062 line, which fixes the start vertex.
Immediately following the 0062 is 0000 which is the start vertex index. At the end, the 0061 line contains the number of vertices in the block, in this case 0004. I don't know the exact purpose of the 0061 line in the game, but it probably helps set up the vertex buffer in some way.

Note that all the vertex blocks start at 0 and contain 4 vertices.

There are many such blocks, although only one will be used at any time. Which one is selected depends on the decision lines:
0027 Based on distance
00480000 A loop number (I think). This produces 11 rectangles at slightly different places, giving the dust trail.
00A3 Based on AGP capability.

I haven't followed the branches through the file, but maybe exp_1 and exp_6 are used in non-AGP mode, with the choice between exp_1 and exp_6 based on distance.

dust.raw is only used in AGP mode.

In the picture above, I tried to simulate the effect in the game by producing a 128x128 .bmp file with the RGB hex values A2,91,75 respectively taken from the 00A7 line. I used the values from dust.raw for the alpha (A) channel.
Note that dust.raw has an alpha value for each colour, meaning that it is theoretically possible to have different levels of transparency for R,G and B. In dust.raw though, the 3 values are always the same.

What is interesting here, is that it is possible to set the colour that becomes transparent. In dust.3 it's that sand colour. Where transparacy masks are used elsewhere, eg clouds, I can't see any way to set the colour meaning that the clouds will always be white.