I have been trying to document my findings well because I'm concerned that some other interesting project will divert my attention before I get to the point of finishing any useful tools, and the documentation would probably be more useful to anyone who wanted to continue my work (if there was any such person) than some half-complete source code

Also, those old flight sims with their big books just make me want to make a big book of my own

With 6 bits per channel, the limitation was 2^(6*3) = 262,144 (256K). At the time the limitation of 256K colours didn't seem so bad (it was a big improvement on what we had before!), but if I recall correctly, if you made a gradient of every available shade of red (i.e. with 64 steps) it wasn't very smooth



Yes, I guess you would have maybe 32 of your 256 colour palette entries reserved for shades of blue for the sky, and as the light faded you would still use those same palette entries but change which of the 262,144 colours they mapped to. I guess the problem was that if you had 32 shades of blue in the sky to start with, and there are only 6 bits of resolution (64 possible values) for each colour channel, you don't have to dim those sky colours very far before two adjacent colours end up looking identical.

On an unrelated note, my copy of the strategy guide turned up yesterday and it has already helped me! From a quick flick through it last night, I saw there were tables showing how many points you get for destroying various targets in each theater. When I was looking in the .dat files, I had worked out there were 12-byte records for each object but didn't know what most of the data in each record was. It hadn't occurred to me that there would be points associated with each object (maybe the fact that I keep flying around in training mode doesn't help since you get no points!) and sure enough I was easily able to work out which field had the score in it. I can only hope it reveals more useful data!

I thought a palette of 256 colors sounded familiar but I couldn't remember so I didn't want to go into more detail. I remember the palette limits being a lot bigger issue. Taking your example. Let's say that you wanted to have every possible available variation of pure red, pure green and pure blue. This would mean that the palette would be using 64 slots for each leaving you the last 64 slots for all of your yellows, oranges, violets, blacks, whites and all the shades in between. So if you actually tried to used too much granularity between shades of a color you'd quickly run out of colors.

That's also assuming you can use every slot. Let us use 32 colors for for the sky. I think it was probably less than this but it's good enough. So you've just used 1/8th (12.5%) of your available colors for something where the colors can't really be used for anything else. You also have to take out any other slots that were used for other color cycling. Now this might just be one color but that's still one more you can't use. If you used too many colors, even as restricted as you were in your options, you'd quickly run out of colors you needed for other things. I think the things that ate the most colors were things related to the cockpit. Since you were looking at that most of the time they had to spend some effort smoothing things out. Another way to think of it is of all the possible color combinations you could have you could only use 1/1024th (0.09765625 %) of them at any one time.

Congratulations on getting your copy. I hadn't thought about the fact that it would help you figure out more of the fields in the .dat files were for but it makes perfect sense. I hope it continues to reveal useful information.

Elf

I remembered one other thing that was an important factor, the resolution. Since it was only 320x200 even if you had the option for more subtle shading you'd have to use a lot of screen real estate to really get to use it.

Elf

Hi all,

I have been doing more hacking and for the really enthusiastic I have updated the reference manual with some more information. Let's talk about what we can actually do with this information, though!

For starters, does anyone else have the desire to do some hacking of their own? If I provided some command-line tools which dump various files in textual format (to the extent that I know what stuff in the files means), would anyone care? Or is it mainly the point-and-click sort of stuff like my ultimate goal, the mission planner, that anyone is likely to use?

I have been thinking about possible modifications to the game that I can make with the information I have. First, I have been thinking about a "realism" modification for the Desert Storm theater. I have been reading a bit about Desert Storm - I've read bits of GWAPS and GAO/NSIAD-97-134 - and it seems that the following changes would make things more realistic:

- remove most SAM sites since most were destroyed in the first few days of the air campaign

- remove all enemy aircraft (I have already verified that this can be done easily)

- remove some missions that would never have actually been flown: the crossed swords (see reference to "Victory Arch" at http://www.globalsecurity.org/military/world/iraq/baghdad-monuments.htm which says that this was off-limits), and maybe the palace (I think I saw mention that this was off-limits somewhere, I would try to find that again) and set these objects to have negative points if you destroy them, just like mosques

- if I recall correctly, for just about every mission in every theater, the target marker triangle (in the radar and map) is in exactly the right place; for the anti-Scud missions at least, I'd like to have that marker not be in the right place so that you have to hunt around, and perhaps have lots of tanks and other vehicles in the area to make the work harder

- from what I've read (I probably should read up on this more), they had "kill box" missions in the actual air campaign where the pilot was meant to attack the highest-value target in a given area; perhaps (if this is somewhat like what happened in real life) the mission could be to find the highest target in a 10nm box centred on the target marker and have a number of groups of vehicles in the area, some tanks and one or two mobile SAM launchers, where destroying at least one of them would achieve the objective

- some missions where precision bombing is required, e.g. the air defence building but with other buildings surrounding it that have negative points, a mobile SAM launcher next to the water towers in Kuwait City ("The Official Strategy Guide" says how you're not supposed to destroy the water towers, although I'm not sure that they actually have negative points) or a group of tanks right next to an electricity generation plant that we designate as "friendly"; possibly some of these targets having quite a bit of AAA around them to encourage use of precision weapons rather than just low-altitude bombing

The removal of lots of SAM sites and all enemy aircraft should allow players to go along with what happened in the real air campaign where, from what I've read, most bombing took place at 16,000ft or more in order to avoid all the AAA. Having Scud launchers and other targets that you actually have to hunt for would keep us busy while we're there! I think overall the missions would be easier, which is how the actual war sounds from my reading, and that appeals to me

So:

- do you think these are good/bad ideas?

- would you actually play this stuff, or isn't this interesting enough for you to go to the trouble of installing the game?

- how would you feel about being the first person to play this stuff, i.e. be a tester?

- I don't like the idea of distributing (only slightly) modified versions of game files - copyright and all that - so I figure I would write some kind of program which lets you back up your existing Desert Storm theater and then apply the changes to it or restore the backup, is that acceptable?

Thanks in advance,
David

This sounds so good, doshea. You might pm Recluse about testing - he was pretty knowledeable about the sim back in the day. I'd be happy to try it but have much less expertise and experience with it.

doshea, I wish I had the time to help you. Any spare modding time I get now is spent on TAW.

I'm checking your progress though, to see if your insight into F15SE3 contains pointers to techniques which may have been used in the stuff we're doing.

Already, you and Scott have given helpful comments on palettes.

I wouldn't be surprised if the palette is the only thing that F15SE3 has in common with any more modern games! On the other hand, looking at information about how one game stores data and links it together might trigger you to think about how another game does the same thing. I guess that means that I should go and read someone else's document about another game Right now though I have no shortage of things to add to the document - I have lots of notes that I've yet to incorporate!

Regards,
David

For anyone who is interested, I have updated the Reference Manual at http://strikeeagleeye.sourceforge.net/doc/index.html with quite a few changes I've made over the last few months, most significantly adding a fair bit of the information I have on the .3dx (3D model) file format. I still have a bit more information to add for this format and a lot of tidying is to do (as is the case for most of the document).

Also, in case anyone cares, the 0x8100 vertex co-ordinate prefix I mentioned is followed by another 16-bit value which I failed to mention, but since this only occurs once in all the files from the game I don't think it is very significant - I haven't got a clue what it is meant to do. I am actually leaning towards the most logical explanation being that the tools Microprose used to generate the models were somehow hard to use, and rather than delete some garbage data from the file it was easier to add a special case in the game engine to ignore it - I recently read an article about game development which suggested that this kind of thing really does happen

Regards,
David

Glad you continue to make progress. Please do keep us posted. And thanks, doshea.