EF2000/TAW hybrid

I’m not sure if anything good will come of this, but it does seem to be possible to use terrain, objects etc, from EF2000 in the TAW game engine with some file conversion. This would allow the dated 1996 EF2000 graphics to be brought up to 1998 standards. 🙂

As an example of how useful this would be, here’s a picture of Luxor airport in Egypt where the fire station has been replaced with an iceberg from EF2000:

Does anybody have any ideas for any practical application?

mikew

Does anybody have any ideas for any practical application?

sking? sledding? or just downhill a$$ sliding. I bet they could have made fortune of that in real life in Luxor 🙂

mikew, that is just an amazing bit of detective work. Both have been around for so many years, and this is the first hint of such a hybridization I’ve heard of. Well done indeed!

Question – when you say terrain apart from objects, just how much is meant by that? Surely not the entire terrain of the EF2000 setting, right? But to what extent can the terrain be modified towards that direction, and away from the current maps?

And now in total fantasy land…if only the (flyable) EF2K itself could be put into TAW! And its co-op campaign!!

Eugene,

As far as I can see it should be possible to transfer the entire EF2000 terrain across. Both games use the same 400x400 terrain tile size. The dumb terrain can be done quite easily but towns,airfields etc will take a bit more work. I’m not sure about the sky though, I guess TAW’s continuous nice weather would be out of place in Norway.

The big question is whether functioning campaigns can be created in a different theatre.

We’d still be limited by the TAW engine, so it looks like a co-op campaign is out.

Some practical application of this hybrid experiment would be to try to see the size of the collision box. Since small building was replaced by large mountain can you crash into it and see what size the collision boundry is for now? That could give us some indication that substitution of 3 file automatically adjust it or we need to look further into ssd maybe.

Polak,

You are correct, the iceberg is not really there as far as the game is concerned...so no skiiing yet. 🙂
You can still crash into the now invisible fire station though.
The collision boxes are described somewhere in the .ssd file. In EF2000 the iceberg has its own .ssd file with the appropriate collision box.
The only EF2000 .ssd I’ve converted so far is sea.ssd. The next step would be to try a hilly terrain to see whether I can crash into it, ie to ensure that TAW can read the height info from EF2000 and that the altimeter works etc. If that works then I’d move on to a tile with buildings on it, etc etc.

For the next stage I replaced the tile north of Luxor with a fjord tile from EF2000. This time I’ve used the fjord .ssd and .3 files. The strange thing is that even though I can dive towards the bottom of the fjord with the radar altimeter showing the appropriate height for the fjord, I can’t crash into the fjord walls. No idea why. 🙁

Hmmmm… Is it also possible to transfer the Typhoon to TAW? I miss a good sim for it *sigh*…

blue_plasma,

Probably not, since the information required for flight models etc is likely to hard coded in the game exe. I’m only using the data files obtained from Krus’s did.dat extractor. There is still plenty to be explored there.

That’s a sad news. I liked no, loved that game. Does anyone know why there are no ambitions to create a hardcore flightsim for the Typhoon?

Its a pity Typhoon was not a more open game. It had a lot of potential. I get the impression that there are parts of Typhoon which were common to TAW. Unfortunately the Typhoon did.dat file appears to be scrambled.

In order to recreate the EF2000 terrain in TAW, the contents of EF2000’s lev folder need to be converted into the same form as used by TAW. In TAW, the file redsea.env contains a list of pointers to which terrain tile .ssd file should be used at a particular location on the 400x400 grid. This is not a direct process and it takes three stages before we end up at the name of the file pointed to in redsea.lst.
The process in EF2000 seems somewhat simpler. The files norway.4ev and norway.4e2 can be combined to form an eqivalent file to redsea.env. The pointers in norway.4ev access directly the terrain tile .ssd names given in the file norway.dat, which can be compared to redsea.lst.

This should allow some swathes of EF2000 dumb terrain to be incorporated into TAW. I doubt that it would work to use the whole map straight away since first we need to handle where to put the airbases etc.

If anybody is interested, the extracted EF2000 data files can be found here (13MB zip file):
http://rapidshare.com/files/18121891/ef2k.zip

Some problems are encountered when trying to port the more complicated EF2000 supershapes. The following picture shows what happens if airfld_1.ssd is partly converted to the TAW format. This airfield containes about 30 separate objects (about the same as Luxor). These objects each have an index number which is linked to each object’s .3 file by the file ssinfo.fn in EF2000’s ss folder. In order to add these objects to TAW, they must be added to the end of TAW’s ssinfo.fn....and their new index numbers used in airfld_1.ssd.

In the picture the textures are not rendered properly due to a small change that is required to each EF2000 .3 file, which I haven’t done. The main problems though are:

1. The runway is too wide and in the wrong place. It works as a runway though.

2. The objects don’t seem to exist in the game. ie they can’t be blown up or crashed into. This is a similar problem to the fjord tile from an earlier post. It means that the EF2000 .ssd files are only partially compatible with TAW. These important differences need to be found before going too much further.

I’m going to have to read this thread a couple times over to grasp it but...

mikew

This would allow the dated 1996 EF2000 graphics to be brought up to 1998 standards. 🙂

Sounds funny but HELL YES, this would be GREAT (comparing EF2000 [1996] to TAW [1998])! I’m thinking the biggest differences are resolution and 3D acceleration.

Interesting pics, mikew.

MGonzales, good to hear from you.

All this is fairly experimental stuff. It’s one thing to swap out a TAW object or single terrain tile from EF2000, but quite another to swap out the entire theatre. This requires total understanding of how the lev folder files work in both games. I’m optimistic that it shouldn’t be too much of a problem though.
Once the terrain is in place, it needs to be brought to life by defining where the borders are, place names, targets, etc, etc … which I was going to worry about later.

Starting to get a bit more familier with the files now. I’ve added an EF2000 mountain/glacier tile (cm3_p.ssd) to TAW’s terrain set....as opposed to just renaming existing TAW files as I did for the fjord example.

There are quite a few changes to be made though:

1. The appropriate EF texture (GLACALL.tm) needs to be copied across to the TAW redxxxx folder. This can be used without modification. EF uses 95x95 pixel tiles compared to TAW’s 96x96.
   I’m still using a TAW palette, I think the EF2000 palettes are slightly different.

2. The cm3_p.3 file needs to be modified slightly so that the texture is rendered correctly.

3. The cm3_p.ssd has to be heavily modified. In fact it’s easier to strip out the topography data block from the EF ssd file and transplant it into a TAW ssd file. The resulting file is >90% EF, but the header and last few bytes are from TAW…it seems to work.

4. In order for the correct .3 file to be selected, the ssinfo.fn file needs the addition of cm3_p to the list. The number at the start of this list needs to be incremented every time a new .3 file is added. The position in this list gives the index number to be used by the .ssd file.

5. The cm3_p.ssd file has to make itself known to the game. This is done by updating the redsea.lst,redsea.asc and redsea.env files in the lev folder. Basically, a new element is added to each of the 3 sections of redsea.lst, taking care to keep the numbers consistent. The total number of objects given at the start of redsea.asc also has to be incremented. This was 999 for the unmodded TAW, but now it’s 1001 since I’ve added EF’s sea tile and this mountain tile.

If TAW is now run, no changes whatsoever should be seen. In order to use the new tile, its object index needs to be called from the redsea.env file. In the following picture I’ve modified redsea.env so that the tile immediately north of Luxor uses this new tile. As far as I can tell, it’s fully functional as a terrain tile. The radar altimeter gives about the correct height above the tile, despite being about 10000 feet higher than Luxor, and the craters can be seen where I’ve cluster bombed it. It can also be crashed into.

I haven’t got a clue why I’m doing this. 🙂

mikew

I haven’t got a clue why I’m doing this.

It is very interesting excercise and example of modding.

However, the results are surpressed by the simple fact that BOTH of DID’s simulations graphically little suck in comparison to the visuals of current games and modern gaming standards. In order to entice and induce further modding some major graphical improvement could be handy.

PS. EF2K and TAW are in different scales. Hard for me to determine what exatly that difference is, but it is evident specially by the photo of runway.

Ah yes, that photo of the airbase probably wasn’t my finest hour. This is what happens when you try to run before you can walk. I was basically using the EF2000 airfld_1.ssd file, but it looks like some objects got mixed up. 🙂
Also, I can fly right through that control tower, so the collision box system isn’t working.

Looking in more detail at airfld_1.ssd shows a lot of differences to say, luxor.ssd, but also many similarities. So, the plan would be to extract the relevent object details from the EF2000 and tranplant them into a TAW file. This is the main reason I updated the Luxor ssd thread a couple of weeks ago.

Note, that even in TAW, some objects have different visual scales. There is a scaling parameter in the ssd file which is used to bring them back into line.

To me the greatest letdown and dissapointment about TAW was its way to portray the height of the terrain. The heightmap, or rather total lack of thereof.

From that point when I realised that 3D mountains and hills make the TAW world look like chocolate bar the charm and enchantment buble bursted completely. I realised that the heights of TAW do not represent true area of Red Sea but they are completely fictitious with those valleys running like artificially dug trenches to accomodate roads, rivers, pipelines and rail.

Perhaps your work of mixing 3D elements from 2 games can restore some sort of landscape randomness and at the same time some degree of compliance with true geographical record.

If we could figure out the height system as described in this post:
../luxor-ssd-and-its-3-files/index.html#101

… then we have enough information to build a terrain editor. The biggest problem (apart from bothering to do it in the first place) is that there are only 25 vertices per tile, and 16 of those comprise the outside straight edges. By some rough calculations, each tile is 2048 units square and each unit is about 8 feet, so the tiles are about 3 miles on each side.

What I don’t know is whether we can double the resolution by having 4 times as many smaller tiles.

mikew

So, the plan would be to extract the relevent object details from the EF2000 and tranplant them into a TAW file. This is the main reason I updated the Luxor ssd thread a couple of weeks ago.

I think this has marvelous potential. An example of how this could be used is in the modding of the ship/sea warfare in TAW The AKULA and VANGUARD class vehicles are pictured in the EF2000 MANUAL as Submarines, as well they are and should be. For some unexplained reason DID converted both of them to the exact same image as the Kirov (Kirov-Class Cruiser) in TAW. WHY?
It would be great if we could convert them back to submarines in TAW. I’m sure the two of you could do that 👍

PS: has anyone played EF2000 enough to have seen submarines in the game?

I’ve taken the akula.3 model from EF2000 and renamed it to dhow.3 to see what it looks like in TAW. It certainly looks like a sub, although I don’t think the texture is displayed properly.

Thank you kind sir! Now that’s what I call a fast roll-out on a major military project. The Akula is a Nuclear-Class Attack Submarine and with the fact that Tomahawks and Cruise Missiles are already possible in TAW, and having access to the Gbvtypes.txt/weapon types file, I’m talkin about a possible way to implement a ultra-quick campaign strategy … I’m talkin GAME-OVER-NOW

After a bit of a layoff, I thought I’d take a fresh look at this.

Instead of adding EF terrain to the TAW set as before, this time I started gradually replacing the TAW terrain with the corresponding EF terrain which is found at the same coordinates. There is a bit of a problem though.
In the following picture, the F22 is flying above Jeddah. At these coordinates in EF2000 there is mountainous terrain. Three mountain peaks can be seen together with four tiles which should attach to them. Only one of them is in the correct orientation. The one in the distance needs to be rotated clockwise by 90deg and the three in the foreground need to be rotated anticlockwise 90deg.

In EF2000, the tile is common for all four orientations and there is a parameter in EF2000’s equivalent of redsea.lst which tells the engine how the tile should be positioned.
I don’t think this is implemented in TAW and to get the same effect I’d need to produce four separate tiles for each of the orientations. At least I think that’s the case. Does anyone know of an example in TAW where the same hilly tile can be seen in different orientations??. A flat tile isn’t a problem since the texture could just be rotated.

blue_plasma

That’s a sad news. I liked no, loved that game. Does anyone know why there are no ambitions to create a hardcore flightsim for the Typhoon?

the sadder truth is that we’re all alone here. most people prefer FPS’s, strategy, racing games and the like. very few know what beauty lies within a flight sim and the talent it takes to be a good dogfighter. that’s why making flight sims isn’t an extremely profitable business.

but on the other hand, we can always dare to take matters into our own hands..
but that quest is tougher than it appears … 🙁

I hear ya Jolly, it’s a real shame, but if you look at most things in life, they are basically a repeated pattern of ups and downs, perhaps in 10-15 years flight sims will be as popular as they were during the 90s!*Optimist*

Yeah! Always look on the bright side. 🙂

I’m now fairly sure that terrain tiles can’t be rotated in TAW, therefore 4 different .ssd/.3 file sets need to be produced. I’ve placed the following 4 .ssd files in sequence in the tile north of Luxor:

• mont1s_1.ssd
• mont1s_2.ssd
• mont1s_3.ssd
• mont1s_4.ssd

These 4 files seem to produce basically the same shape but in different orientations. In fact mont1s_3 looks like it is exactly mont1s_1 rotated through 180deg.
I’m hoping now to use the information from the respective .ssd files to work out how the topography system works. This is quite tough since it can’t be seen.

Here’s a picture. Note the heading of the plane in each case.

3D objects from EF2K to TAW could be interesting excercise as long as they fit the new terrain. I like the look of mountain and with some texture play we could get rid of that snowy slopes. In return we can get some new terrain 3D features enhancing TAW terrain even further.

I really would like to

1. make the valleys little less pronounced
2. try to push the horizon to reveal more terrain
3. make more detailed LODs been seen at higher distances than now in the game

In the picture above with the mountains, the EF2000 terrain is drawn much closer than it is in TAW, which is quite distracting. I’ve used EF2000’s own slightly modified .3 files for this.
Presumably, there are parameters which can be changed in the .3 file which affect when the terrain is drawn and LOD for objects.

In order to try and understand the terrain topology system, here is the topology part of mont1s_1.ssd:

00fe65ff00fe00fc65ff00fc00fc65ff00fe00fc00fe00fc00fe65ff65ff00fe00fe00fc00fc00fc00fe0000ff7f00009b0000800000000000000000ff7f000000000002000200020000
00fc65ff00fc00fe65ff00fe00fe6fff00fc00fc00fe00fc00fe65ff6fff00fc00fc00fe00fe00fe00fc81fdf37f7f029a00f97f7f020000f4ff7f02078000000000ff01000200020000
440065ff2efe00fe6fff00fc00fe65ff00fe00fe440000fc2efe65ff6fff44002efe00fe00fc00fe00fecefff97f7f02a40067800000e2f5e2f57ffd937f000000006e02fe0145020000
00fe6fff00fc440065ff2efe000065ff00fc00fe440000fc2efe65ff6fff00fe00fc44002efe000000fc7f02f97fb3ff9800f97f81fd0000ffffb3ff01800000000044022e0200020000
440065ff2efe00026fff00fc000065ff00fc0000000200fc2efe65ff6fff44002efe000200fc000000fc81fdf97f4d009d0085f00000f180f7807cfd7b0f00000000f401fc0132020000
00026fff00fc440065ff2efe000265ff1cfe4400000200fc2efe65ff6fff000200fc44002efe00021cfe1800fa7f5e02a3000000a2fdfa7fff7fe8ff0000000000002e02bc011c020000
000265ff1cfe000465ff00fc00026fff00fc0002000400fc1cfe65ff6fff00021cfe000400fc000200fc7f02f47f5e02990000005e02068007807f020b00000000001b0200021c020000
000465ff00fc000265ff1cfe000465ff00fe0002000400fc1cfe65ff65ff000400fc00021cfe000400fe0000ff7f00009b0000000000ff7fff7f00000000000000001c02000200020000
fffd7afe000000fc65ff00fe00fc7ffe000000fcfffd00fe00007afe65fffffd000000fc00fe00fc00002401c174723468010280400100007dff8ecbc2740000000001023102ff010000
00fc65ff00fefffd7afe000000fe65ff00fe00fc00fe00fe00007afe65ff00fc00fefffd000000fe00fe0000547464356201ff7f0000000000006435ac8b00000000ff01330200020000
4500e9fd000000fe65ff00fefffd7afe0000fffd450000fe0000e9fd65ff4500000000fe00fefffd0000431c70711f34ca01cc83f11e000067f36dcde874000000008f02300257020000
00fe65ff00fe4500e9fd0000440065ff2efe00fe450000fe0000e9fd65ff00fe00fe4500000044002efe98f91163cc50a101997f00001e0ad5070d513e9d000000006b02580245020000
4500e9fd0000000265ff1cfe440065ff2efe440000021cfe0000e9fd65ff4500000000021cfe44002efe47032b63dc509c01caffe450ce9c0b8067023c02000000006602bc0159020000
000265ff1cfe4500e9fd0000ef017ffe0000450000021cfe0000e9fd65ff00021cfe45000000ef0100000ad9a66e3633e301f1fb17c98d73db798c213814000000006502bc0118020000
ef017ffe0000000465ff00fe000265ff1cfeef01000400fe00007ffe65ffef010000000400fe00021cfe0203897302374f010f04e936738c1a807504a1fd000000004102ff0118020000
000465ff00feef017ffe000000047ffe0000ef01000400fe00007ffe65ff000400feef010000000400000000c27473345f0100008dcbc274ff7f00000000000000003102110231020000
00fcfdfd0002fffd7afe000000fc7ffe000000fcfffd00000002fdfd7ffe00fc0002fffd000000fc000036010e7c7f1f7e010000801ff08302802d014c00000000000f02ff0110020000
fffd7afe000000fcfdfd000200feb7fdfd0100fc00fe00000002b7fd7afefffd000000fc000200fefd0179108b76622dab013c0036d28777ef7eb4f0e4f9000000000902040221020000
00feb7fdfd014500e9fd0000fffd7afe0000fffd45000000fd01b7fd7afe00fefd0145000000fffd0000021d70748c2cd701c4ffca2d79885583011b970a00000000ec01550221020000
4500e9fd000000feb7fdfd012700a8fdf30000fe45000000fd01a8fde9fd4500000000fefd012700f30031147579fb22f001d8f029dfc87a7c7d7de833090000000039020b02fd000000
0002b7fd70014500e9fd00002700a8fdf3002700000200007001a8fde9fd00027001450000002700f300c2f3747b821f0a024f8414fc50df71e16ddead77000000000802fb00e9010000
4500e9fd00000002b7fd7001ef017ffe00004500000200007001b7fd7ffe4500000000027001ef01000068dac46ac33bd201bb78832a000027ec5e38cf8e000000009101a001c3010000
0004fdfd0002ef017ffe00000002b7fd7001ef01000400000002b7fd7ffe00040002ef0100000002700139e0526c563cc001d6854defa5ddcceae2bd876b000000007102990118020000
ef017ffe00000004fdfd000200047ffe0000ef01000400000002fdfd7ffeef01000000040002000400000000107c801f7501ff7f000000000000801ff083000000001102100211020000
00fcadfd000400feb7fdfd0100fcfdfd000200fc00fefd010004adfdfdfd00fc000400fefd0100fc00023f114f7d941333020000c21389812b810a11a90200000000fe01040206020000
00feb7fdfd0100fcadfd000400feb7fd000400fc00fefd010004adfdb7fd00fefd0100fc000400fe000481fdf97f00003e0200000000ff7ff97f7f020000000000000302000203020000
00feb7fd00042700a8fdf30000feb7fdfd0100fe2700f3000004a8fdb7fd00fe00042700f30000fefd017b03f37f000056020000000000800d807b030000000000000d03270203020000
2700a8fdf30000feb7fd00040000adfd000400fe2700f3000004a8fdb7fd2700f30000fe0004000000047f02f97f4fff58029ef9d100d67fd07f8afd6506000000002703ff010d030000
0002b7fd00042700a8fdf3000000adfd000400000002f3000004a8fdb7fd000200042700f3000000000481fdf87f0fff5a02078081fd0000fcfff100ff7f00000000d9010d0300020000
2700a8fdf3000002b7fd00040002b7fd700127000002f3000004a8fdb7fd2700f3000002000400027001f2fbef7f00005802b17bec03b020ac2009013f840000000090027a02e9010000
0004adfd00040002b7fd70010002b7fd00040002000470010004adfdb7fd0004000400027001000200047f02f97f00003e0207807f02000000000000ff7f000000000002900200020000
0002b7fd70010004adfd00040004fdfd00020002000470010004adfdfdfd00027001000400040004000282e97f7c73135b022a7ab3105b22e11e9a183e86000000009702f60118020000

The above is split into 32 lines which (I think) describe the triangles making up the terrain tile.
This is borne out by taking the first 18 bytes of each line and treating them as XYZ coordinates:

00fe65ff00fe 00fc65ff00fc 00fc65ff00fe
00fc65ff00fc 00fe65ff00fe 00fe6fff00fc
440065ff2efe 00fe6fff00fc 00fe65ff00fe
00fe6fff00fc 440065ff2efe 000065ff00fc
440065ff2efe 00026fff00fc 000065ff00fc
00026fff00fc 440065ff2efe 000265ff1cfe
000265ff1cfe 000465ff00fc 00026fff00fc
000465ff00fc 000265ff1cfe 000465ff00fe
fffd7afe0000 00fc65ff00fe 00fc7ffe0000
00fc65ff00fe fffd7afe0000 00fe65ff00fe
4500e9fd0000 00fe65ff00fe fffd7afe0000
00fe65ff00fe 4500e9fd0000 440065ff2efe
4500e9fd0000 000265ff1cfe 440065ff2efe
000265ff1cfe 4500e9fd0000 ef017ffe0000
ef017ffe0000 000465ff00fe 000265ff1cfe
000465ff00fe ef017ffe0000 00047ffe0000
00fcfdfd0002 fffd7afe0000 00fc7ffe0000
fffd7afe0000 00fcfdfd0002 00feb7fdfd01
00feb7fdfd01 4500e9fd0000 fffd7afe0000
4500e9fd0000 00feb7fdfd01 2700a8fdf300
0002b7fd7001 4500e9fd0000 2700a8fdf300
4500e9fd0000 0002b7fd7001 ef017ffe0000
0004fdfd0002 ef017ffe0000 0002b7fd7001
ef017ffe0000 0004fdfd0002 00047ffe0000
00fcadfd0004 00feb7fdfd01 00fcfdfd0002
00feb7fdfd01 00fcadfd0004 00feb7fd0004
00feb7fd0004 2700a8fdf300 00feb7fdfd01
2700a8fdf300 00feb7fd0004 0000adfd0004
0002b7fd0004 2700a8fdf300 0000adfd0004
2700a8fdf300 0002b7fd0004 0002b7fd7001
0004adfd0004 0002b7fd7001 0002b7fd0004
0002b7fd7001 0004adfd0004 0004fdfd0002

These can be plotted out:

The next 12 bytes in each line seem to give the min and max values of X,Z and Y in that order:

XXXX XXXX ZZZZ ZZZZ YYYY YYYY
00fc 00fe 00fc 00fe 65ff 65ff
00fc 00fe 00fc 00fe 65ff 6fff
00fe 4400 00fc 2efe 65ff 6fff
00fe 4400 00fc 2efe 65ff 6fff
0000 0002 00fc 2efe 65ff 6fff
4400 0002 00fc 2efe 65ff 6fff
0002 0004 00fc 1cfe 65ff 6fff
0002 0004 00fc 1cfe 65ff 65ff
00fc fffd 00fe 0000 7afe 65ff
00fc 00fe 00fe 0000 7afe 65ff
fffd 4500 00fe 0000 e9fd 65ff
00fe 4500 00fe 0000 e9fd 65ff
4400 0002 1cfe 0000 e9fd 65ff
4500 0002 1cfe 0000 e9fd 65ff
ef01 0004 00fe 0000 7ffe 65ff
ef01 0004 00fe 0000 7ffe 65ff
00fc fffd 0000 0002 fdfd 7ffe
00fc 00fe 0000 0002 b7fd 7afe
fffd 4500 0000 fd01 b7fd 7afe
00fe 4500 0000 fd01 a8fd e9fd
2700 0002 0000 7001 a8fd e9fd
4500 0002 0000 7001 b7fd 7ffe
ef01 0004 0000 0002 b7fd 7ffe
ef01 0004 0000 0002 fdfd 7ffe
00fc 00fe fd01 0004 adfd fdfd
00fc 00fe fd01 0004 adfd b7fd
00fe 2700 f300 0004 a8fd b7fd
00fe 2700 f300 0004 a8fd b7fd
0000 0002 f300 0004 a8fd b7fd
2700 0002 f300 0004 a8fd b7fd
0002 0004 7001 0004 adfd b7fd
0002 0004 7001 0004 adfd fdfd

The formatting on this board sucks. 😡

The 12 bytes after that give the X and Z coordinates of each triangle. I guess this is useful from a 2D perspective:

XXXX ZZZZ XXXX ZZZZ XXXX ZZZZ
00fe 00fe 00fc 00fc 00fc 00fe
00fc 00fc 00fe 00fe 00fe 00fc
4400 2efe 00fe 00fc 00fe 00fe
00fe 00fc 4400 2efe 0000 00fc
4400 2efe 0002 00fc 0000 00fc
0002 00fc 4400 2efe 0002 1cfe
0002 1cfe 0004 00fc 0002 00fc
0004 00fc 0002 1cfe 0004 00fe
fffd 0000 00fc 00fe 00fc 0000
00fc 00fe fffd 0000 00fe 00fe
4500 0000 00fe 00fe fffd 0000
00fe 00fe 4500 0000 4400 2efe
4500 0000 0002 1cfe 4400 2efe
0002 1cfe 4500 0000 ef01 0000
ef01 0000 0004 00fe 0002 1cfe
0004 00fe ef01 0000 0004 0000
00fc 0002 fffd 0000 00fc 0000
fffd 0000 00fc 0002 00fe fd01
00fe fd01 4500 0000 fffd 0000
4500 0000 00fe fd01 2700 f300
0002 7001 4500 0000 2700 f300
4500 0000 0002 7001 ef01 0000
0004 0002 ef01 0000 0002 7001
ef01 0000 0004 0002 0004 0000
00fc 0004 00fe fd01 00fc 0002
00fe fd01 00fc 0004 00fe 0004
00fe 0004 2700 f300 00fe fd01
2700 f300 00fe 0004 0000 0004
0002 0004 2700 f300 0000 0004
2700 f300 0002 0004 0002 7001
0004 0004 0002 7001 0002 0004
0002 7001 0004 0004 0004 0002

…and finally, the rest of each line. This is where I’m stuck. I’m fairly sure these values somehow give the angles between the vertices though. The spaces are my own interpretation:

0000 ff7f 0000 9b00 0080 0000 0000 0000 0000 ff7f 00000000 0002 0002 0002 0000
81fd f37f 7f02 9a00 f97f 7f02 0000 f4ff 7f02 0780 00000000 ff01 0002 0002 0000
ceff f97f 7f02 a400 6780 0000 e2f5 e2f5 7ffd 937f 00000000 6e02 fe01 4502 0000
7f02 f97f b3ff 9800 f97f 81fd 0000 ffff b3ff 0180 00000000 4402 2e02 0002 0000
81fd f97f 4d00 9d00 85f0 0000 f180 f780 7cfd 7b0f 00000000 f401 fc01 3202 0000
1800 fa7f 5e02 a300 0000 a2fd fa7f ff7f e8ff 0000 00000000 2e02 bc01 1c02 0000
7f02 f47f 5e02 9900 0000 5e02 0680 0780 7f02 0b00 00000000 1b02 0002 1c02 0000
0000 ff7f 0000 9b00 0000 0000 ff7f ff7f 0000 0000 00000000 1c02 0002 0002 0000
2401 c174 7234 6801 0280 4001 0000 7dff 8ecb c274 00000000 0102 3102 ff01 0000
0000 5474 6435 6201 ff7f 0000 0000 0000 6435 ac8b 00000000 ff01 3302 0002 0000
431c 7071 1f34 ca01 cc83 f11e 0000 67f3 6dcd e874 00000000 8f02 3002 5702 0000
98f9 1163 cc50 a101 997f 0000 1e0a d507 0d51 3e9d 00000000 6b02 5802 4502 0000
4703 2b63 dc50 9c01 caff e450 ce9c 0b80 6702 3c02 00000000 6602 bc01 5902 0000
0ad9 a66e 3633 e301 f1fb 17c9 8d73 db79 8c21 3814 00000000 6502 bc01 1802 0000
0203 8973 0237 4f01 0f04 e936 738c 1a80 7504 a1fd 00000000 4102 ff01 1802 0000
0000 c274 7334 5f01 0000 8dcb c274 ff7f 0000 0000 00000000 3102 1102 3102 0000
3601 0e7c 7f1f 7e01 0000 801f f083 0280 2d01 4c00 00000000 0f02 ff01 1002 0000
7910 8b76 622d ab01 3c00 36d2 8777 ef7e b4f0 e4f9 00000000 0902 0402 2102 0000
021d 7074 8c2c d701 c4ff ca2d 7988 5583 011b 970a 00000000 ec01 5502 2102 0000
3114 7579 fb22 f001 d8f0 29df c87a 7c7d 7de8 3309 00000000 3902 0b02 fd00 0000
c2f3 747b 821f 0a02 4f84 14fc 50df 71e1 6dde ad77 00000000 0802 fb00 e901 0000
68da c46a c33b d201 bb78 832a 0000 27ec 5e38 cf8e 00000000 9101 a001 c301 0000
39e0 526c 563c c001 d685 4def a5dd ccea e2bd 876b 00000000 7102 9901 1802 0000
0000 107c 801f 7501 ff7f 0000 0000 0000 801f f083 00000000 1102 1002 1102 0000
3f11 4f7d 9413 3302 0000 c213 8981 2b81 0a11 a902 00000000 fe01 0402 0602 0000
81fd f97f 0000 3e02 0000 0000 ff7f f97f 7f02 0000 00000000 0302 0002 0302 0000
7b03 f37f 0000 5602 0000 0000 0080 0d80 7b03 0000 00000000 0d03 2702 0302 0000
7f02 f97f 4fff 5802 9ef9 d100 d67f d07f 8afd 6506 00000000 2703 ff01 0d03 0000
81fd f87f 0fff 5a02 0780 81fd 0000 fcff f100 ff7f 00000000 d901 0d03 0002 0000
f2fb ef7f 0000 5802 b17b ec03 b020 ac20 0901 3f84 00000000 9002 7a02 e901 0000
7f02 f97f 0000 3e02 0780 7f02 0000 0000 0000 ff7f 00000000 0002 9002 0002 0000
82e9 7f7c 7313 5b02 2a7a b310 5b22 e11e 9a18 3e86 00000000 9702 f601 1802 0000

All your assumptions look plausible from outside. But what do I know without looking closer and tracing it byte by byte.

I would add though that what you call 2D perspective could be simplified 3D model which could be rendered in certain situations.

The last part, and it is just my pure guess, should contain description of polygons with normal (facing) and texture name and its coordinates. However, it may be as well that the texture is assigned to this single 3D object in different way (i.e. through that redsea map) than it would be assigned if regular manner.

I will try to dig out some materials describing how terrain rendering was done during those rather older days. Nowadays it is done little differently.

for faster access…

A quick conversion attempt at replacing the F22 with the EF2000 turned out better than expected, although there is still plenty to do.
SEF2000’s textures had to copied across to the TAW red1000 folder and redsea.ini had to be edited to add these texture index numbers after TAW’s. The file efa.3 was then edited to match these new texture numbers and then renamed to f22usa2.3.

mikew, you’re on fire man! Nice work.

Good work Mikew 👍 It can be a simpler conversion using the EF20001.3 substitution. The cockpit detail and features are definitely an upgrade for TAW but what about the canards and rudder implementation?

Good work. Perhaps this could atract more european crowd. Once I remember someone’s said that they were not into US tactical fighter, but would gladly fly Eurofighter here again.

Thanks guys,

DrKevDog

…but what about the canards and rudder implementation?

Now, there’s a good question.

The reason I did this exercise now was because Polak mentioned f22.ssd in another thread. When I looked at this, I noticed it didn’t contain references to any of the F22 control surfaces, f22_23.3 etc.
So is the F22 made up of more than one ssd at the highest LOD? Maybe not, otherwise I’d expect to see the F22 rudders and elevators (flaperons?) superimposed on the EF2000 since I’m still using f22.ssd with efa.3. So how are the control surface .3 files accessed? I don’t know. It’s possible that one .3 file can call another, but I haven’t seen a mechanism for that before.

What we do see on the above picture, is the F22 pylons, but maybe that is to be expected if the pylons are separate objects called up in f22.ssd. Those screenshots were taken in the take off training mission. It’s quite amusing the see the EF2000 with the standard F22 weapon loadout for this mission. Each rocket pod is about the same size as the EF2000 wing. I guess the F22 is bigger than the EF2000 in real life, but I suspect the model scaling between the two games isn’t the same.

Another question relates to the cockpit. Where is the layout described? Thanks to MGonzales’ investigation we know that a lot of the behaviour is controlled by the files in the huddle folder, but not how the whole cockpit goes together. I thought it might have been the main .3 file (f22usa2.3) but after replacing it with efa.3 the standard F22 cockpit was still used.

mikew

So is the F22 made up of more than one ssd at the highest LOD? Maybe not, otherwise I’d expect to see the F22 rudders and elevators (flaperons?) superimposed on the EF2000 since I’m still using f22.ssd with efa.3. So how are the control surface .3 files accessed? I don’t know. It’s possible that one .3 file can call another, but I haven’t seen a mechanism for that before.

What we do see on the above picture, is the F22 pylons, but maybe that is to be expected if the pylons are separate objects called up in f22.ssd.

I believe the Pylons are related to f22pylon.3 and _mtpylon.ssd, the control services do not seem to have seperate corresponding SSD files. I want find time to pull out some of my old notes regarding the hybrid experiments previously undertaken. They may give more insight.

DrKevDog

I believe the Pylons are related to f22pylon.3 and _mtpylon.ssd, the control services do not seem to have seperate corresponding SSD files. I want find time to pull out some of my old notes regarding the hybrid experiments previously undertaken. They may give more insight.

Anything you’ve got will be helpful.
I still don’t know how the control surfaces are defined, although I haven’t looked very hard. It’s maybe time to look deeper into the TAW’s F22 ssd file. This file has some more elements in it than all the other aircraft ssds…