mikew

Well, the TAW (and most other) did.dat files are of this form: The first 4 bytes are pointer to to the index section at the end of the file. In the case of TAW's this is 0x03cc22ae which gets us to this point: At this point are 4 16-bit numbers: 0x312c=12588 The number of files in the archive 0x0069=105 Number of path specifiers 0x0047=71 Number of file extensions 0x06e1=1761 Number of bytes until the start of the index (ie to the point after the paths and extensions) are listed: Now we have the list proper and there are 12 bytes for each of the 12588 files: The first 4 bytes are a mysterious index, then 4 bytes for the offset in did.dat, finally 4 bytes for the file size. In this case we have: Index=0x8006c719, Offset=0x02bd558a, Size=0x00000068 The hope would be that this 'index' is a compressed version of the filename, but hope is fading... These 'index' numbers increment in a strange way, the differences don't correspond to the compressed or uncompressed sizes of the files they relate to. This index is of TFX's 3460 files, but you get the idea. I've left the index as hex, but converted the offsets and sizes to decimal: 0 80117f36 1572576 415 1 8020f12b 1714256 421 2 802fc869 3142886 40 3 80310755 1706269 432 4 80416965 1068735 206 5 8045e661 3154385 240 6 80487169 1397285 587 7 8052fd69 1248725 526 8 805fc74a 2916069 940 9 80624825 3132188 40 10 806d494a 1881578 1702 11 8075a665 3155401 267 12 8078b479 3117002 40 13 807b5549 1708292 536 14 8080b759 1371479 859 15 80861761 1068095 437 16 80897c35 3169674 152 17 808b6635 3171708 152 18 808d6835 3173492 152 19 808dcb35 1571740 836 20 808fdb50 3274013 4610 21 80903553 2814718 607 22 80910579 1227034 346 23 80913f53 2819051 156 24 80923953 2819948 156 25 809c1532 1674678 122 26 80a31f35 1583159 196 27 80a38c23 3162430 183 28 80a51935 1585754 308 29 80ab154d 1712500 655 30 80b93c35 3171252 152 31 80bb2635 3173120 124 32 80bd2835 3176176 152 .... 2857 afcfa293 10413207 169 2858 afd60c8a 2541536 5756 2859 afd7a493 10376338 214 2860 afd8a291 10378145 246 2861 afda332b 1715744 1156 2862 afdaa5d4 1939414 141 2863 afdfaaa8 3213531 82 2864 afe9ffd9 1594625 302 2865 aff993a9 1885281 130 2866 affbb7a0 1961241 552 2867 30209303 1511452 565 2868 30db9c02 1981640 15589 2869 3210a202 3159339 30 2870 3966dc01 333934 5678 2871 3c168102 3496343 133 2872 3e3cb702 1840737 204 2873 3f3eb502 1895112 1830 2874 40060605 1043223 4895 2875 40ba5904 1640423 5796 2876 41080405 1048118 3733 ..... 3445 7f095d29 2809104 603 3446 7f31fc35 3156283 40 3447 7f3f522e 2265448 140 3448 7f498535 1502889 431 3449 7f4d9d35 1503320 412 3450 7f632629 7075180 6017 3451 7f845429 3194679 40 3452 7f87912d 1656202 756 3453 7fb41429 3194919 40 3454 7fccf939 1222871 565 3455 7fd5d638 3390152 8639 3456 7fd9282a 2092604 198 3457 7fe9a529 1918678 113 3458 7feadc2c 3196081 50 3459 7ff3e635 4247747 120866

Splendid! You're making more progress than me.....now I remember why I gave up on this extraction stuff in 2007.

Sounds good to me. I think DKD has been deeper into this. I isolated the TFX .3 files just yesterday, although without names. I haven't done anything with them yet since I'm more interested in the extraction process.

Interesting! Particularly about the EF2000 did.dat file sizes. Could you post the exact sizes, down to the last byte so that I can compare them with what I have?

EF2000? Pah! What we really want is TFX.....

I did extract the ADF files, although without their proper names. It was a long time ago, but I believe I created a script to at least categorize the files into .3, .ssd etc. I'll check later.... It might be an idea to have another look at the did.dat file structure to see if it's possible to extract all the files (with names!) using a standalone tool. I'll start a thread on the subject after I've gathered some information.

Thanks HF, but despite the thread title we were talking about EF2000.

Nice! There is only one texture folder, but there are many palettes for day and night with various weather. I haven't looked into the EF files in much detail, but the pd_cr.txt etc, files in the 'lev' folder may help determine when each palette is used.

Looking good indeed.

I've dug out some parser code and I seem to treat the 0004 type the same as 0000 (and 0020) in terms of finding the start of the bytecode. There may be only 0000 and 0004 types in EF2000. I haven't seen anything else. EDIT: Confirmed that there is only 0000 and 0004 EDIT2: ...and these are the 0004 files: aim_9x.3 airb1.3 airbrake.3 alarm.3 amraam.3 asraam.3 asraam1.3 bl755.3 canardl.3 canardr.3 crv7.3 durand.3 durandal.3 empty.3 f0agm65g.3 flapl.3 flapr.3 fueli.3 fuelo.3 fueltank.3 full.3 gbu12.3 gbu_16.3 g_line.3 ianraam.3 laser_st.3 lpamraam.3 lps225.3 lxamraam.3 lxs225.3 mamraam.3 mav_ir.3 mav_tv.3 mk83.3 mlamraam.3 mpbl755.3 mpdurand.3 mpgbu12.3 mpmk82.3 mramraam.3 mtpylon.3 mxbl755.3 mxdurand.3 mxgbu12.3 mxmk82.3 neilch.3 paim_9s.3 palamo.3 palarm.3 pamraam.3 paphid.3 parcher.3 pas7kery.3 pasraam.3 pbl755.3 pcrv7.3 pdurand.3 pecm.3 pf250_hd.3 pfab250.3 pfab500.3 pfueli.3 pfuelo.3 pgbu12.3 pgbu16.3 pian.3 pkab500l.3 pkilter.3 plaser.3 pmav_ir.3 pmav_tv.3 pmk82.3 pmk83.3 pmoskit.3 prbk500.3 ps225x.3 ps5_rock.3 ps_eagle.3 pylon.3 rudder.3 rxamraam.3 rxs225.3 wheell.3 wheelm.3 wheelr.3 xaim_9s.3 xalamo.3 xalarm.3 xamraam.3 xaphid.3 xarcher.3 xas7kery.3 xasraam.3 xbl755.3 xcannon.3 xcrv7.3 xdurand.3 xf250_hd.3 xfab250.3 xfab500.3 xfueli.3 xfuelo.3 xgbu12.3 xgbu16.3 xkab500l.3 xkilter.3 xlaser.3 xmav_ir.3 xmk82.3 xmk83.3 xmoskit.3 xrbk500.3 xs225x.3 xs5_rock.3 xs_eagle.3 yamraam.3 ysam.3

I'm not working on anything right now , but a couple of months ago I tried to modify the TAW .3 file parser to deal with EF2000's .3 files and encountered these problems. Some of the EF files have the number of vertices just before the 0th bytecode as in TAW, but most seem to have ffff which required some changes to my 'find the ffff' routine. I think there are some different opcodes as well but don't remember exactly, and there were about 6 files that I couldn't handle at all since they bear little relation to any .3 file previously encountered....so I ignored them.

Glad you're still around. There are plenty of rendering order artefacts in the game, so I may have to play it to try and gather evidence. It may be that the game creates an internal rendering order list based on the 'distance' to each object from the camera.

Oh, I don't know. How many Girl Scouts read this forum?

Well, took a bit of upgrading but finally got it working.

Speaking of germans, here's the latest news from newsbiscuit.com: New study says rentable German liver sausage is the leased wurst option

I love that 'not so subtle' cigarette advert.

Well deserved indeed. Judging by the comments associated with the article, it appears not everyone feels the same way, eg, "Good here's an opportunity to analyze the steel and see if there is any evidence of the use of explosives."

I hate mentioning problems with the viewer since it comes across as ungrateful...but what's the plan to deal with the rendering order problem in eg luxor.ssd? It appears that the terrain is drawn last. Is there anything in particular I should be investigating? Summer activities are playing havoc with my 'Quality TAW time' though.

Oh yes. Not much scope for error really....

I would have thought that if a model index doesn't appear in any loaded ssd file, it will never be called....unless it is one of those that are not referenced by any ssd file, eg the f22_xx.3 control surface models, but I dont think these appear in ssinfo.fn anyway

I don't think those files are loaded since they are not part of any scenario. They are probably part of the did.dat archive file though.

Very likely. I need to sort out my TAW folders.... Thanks for the update. It'll be a couple of days before I can try it though.

May be wrong, but in the Options screen, the two camos gave opposite formation light behaviour in the Luxor takeoff training mission. I'm in the arctic with a Linux laptop and sporadic cellular coverage for a few days, so can't try the game to confirm....

Regarding formation lights, I think they are hardcoded on for f22usa1.3 and off for f22usa2.3 (or vice versa). for 007d and 007e

I took the PSU back to the shop and swapped it with this: http://www.ocztechnology.com/ocz-z-series-850w-power-supply.html ....but get exactly the same problem. How hard can it be to change a frikkin PSU? Thanks for the link DKD, but I'm giving up for the time being.