Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrKevDog

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DrKevDog

    Interpretation of SSD files

    Okay I now see that there are three to which this static target list applies and has common namespace. In tfx3 in IDA, the off_6652C8 enumerates that list and in tfx2 (superw.dat) the AAAA list may be the one at DGROUP:0056BC40. thanks about the EF2000 debug, I find it much more useful than that in tfx3 although I seem to recall Krycztij eluding to a dual screen process which I have not yet discovered. There are still some things I wish to improve upon in the use of the process, for example: initially I could not get the collision boxes to remain stable for viewing. somehow I discovered that if I get the camera in a position of displaying an unstable CBox and I pressed the "C" key, all the boxes became stable. Do you know anything about that?
  2. DrKevDog

    Interpretation of SSD files

    Testing the collision boxes problems should work just as well for any test platform, as long as the TARGET_AREA_DATA / TARGPOS formats are identical. I think it is important to consider the progression of changes from tfx2 to tfx3 in the analysis of the target data features. A significant question for me is are the tfx2 and tfx3 data read differently? There are a number of obvious questions, for example, tfx3 has a unique campaign mode which is tied intricately to the target area data throught the AWACS mode GUI much differently than in tfx2. There is a lot here to re-consider from the 2011 analysis, when that target type list was discovered. Take for example the columns you have listed as "CBOX TYPE" and TARGETS TYPE", I would ask you to take a look at the "STRATVAL.txt" document in the F22DATA directory. It is clear from the values in your 2 lists that the values in those 2 columns are identical and if you compare the target types in the list you eluded to, you will find that it does not jibe as an ENUM to the list I found previously and is more reasonably explained as a stratval type-pointer. This may suggest a connection to target values and, potentially, campaign score value assignments. Looking in the executable there are 3 stratval errors which may be of some value in understanding the scope of these values. They state that, on some level, strategic values can be identified as Static, Flight and/ or Group. First, however, I think we need to declare our objective. If it is just to add a target type to the TFXplorer project, it probably isn't necessary to confirm that "stratval" is or is not involved in these SSD functions. I have decided to proceed in this analysis for the TFX2 and 3 knowledge base objectives. I don't know if you received the updated TFXplorer so I decided to look at what I do have that might be of some benefit. There is a mechanism I use in EF2K to turn on the collision boxes which may be of good help in answering some of your questions; I can also turn on the terrain collision triangles and other trackers. To summarize on the original question regarding: TARGPOS000000AAAAXXXXYYYYZZZZBBBB. I believe that AAAA is the Stratval number and I agree that BBBB is rotation as you deciphered it but is that also true for tfx2 as it is for tfx3?
  3. DrKevDog

    Interpretation of SSD files

    I have been working on a similar SSD project only not as ambitious as yours and in Tfx3. I had hoped to find data to help me understand the line in the World Info file: "TARGETSPACE 8276". It seems to me there ought to be a way to differentiate Target space from non-target space in the world. I have not, and that said, most simple, flat tiles do not have Target Area data so perhaps that presence is necessary. In a TFX3 target tile SSD, there are 3 things I would examine: 1. TARGET_AREA_DATA for correct target-tile type 2. TARGETS for individual targets Strategic Value and correct position 3. COLLISION_BOXES for Strategic Value and correct position I would also look at the Campaign.trg as you eluded to... I am very interested in your creating a viable SSD and look forward to the details of your success.
  4. DrKevDog

    Interpretation of SSD files

    Tricky, tricky, tricky
  5. DrKevDog

    Interpretation of SSD files

    Your statement about 'debris/explosions' I agree with but I'm not thinking it's collateral. What we have done before generated statements in my notes suggesting that the 4F opcode lines, in addition to defining the coordinates, gives a lookup value for the specific index in the list of explosions found in the explosions section of the redxxxx.txt files. 0 0 ex_l_1 1 1 ex_l_2 2 2 ex_l_3 3 3 ex_l_4 4 4 ex_l_5 5 5 ex_w_1 6 6 ex_hit1 7 7 ex_hit3 8 8 ex_hit5 9 9 ex_can_l 10 a ex_smk_1 11 b ex_smk_2 12 c ex_smk_3 13 d ex_smk_4 14 e ex_smk_5 15 f fx_hit 16 10 fx_miss 17 11 ex_can_w 18 12 ex_lcrsh 19 13 ex_wcrsh 20 14 ex_vol_1 21 15 ex_vol_2 22 16 ex_vol_3 23 17 ex_vol_4 24 18 ex_vol_5 25 19 ex_acrsh 26 1a ex_ls1 27 1b ex_ls2 28 1c ex_ls3 29 1d ex_ls4 30 1e ex_ls5 31 1f ex_smks1 32 20 ex_smks2 33 21 ex_smks3 34 22 ex_smks4 35 23 ex_smks5 36 24 ex_vols1 37 25 ex_vols2 38 26 ex_vols3 39 27 ex_vols4 40 28 ex_vols5 If that is correct, it would indicate that the explosions referenced for damage levels 1,2 &3, for rig_1.ssd is ex_smks2 and that for damage level 4 is ex_smks1. The 5 ex_smks ssd files are nearly identical with the basic difference being a gradient of scale (block 6).
  6. DrKevDog

    Back to TFX1

    I do hope you can continue your research, it's very interesting that it did not work and I would think it most helpful to know why. Buying a new card is tricky these days and I've lived this far without the cryptomining feature, I'm just grateful for my powerful dedicated AGP instead..LOL!
  7. DrKevDog


    Thanks! I did go back to my files and found your TFX 1 unknown SPRs. That is helpful, thanks.
  8. DrKevDog


    I have been following these threads and, as always, they prompt my curiosity about a number of things. First let me say thanks to Krycztij for the updates. I have been doing some work on the terrain recently and was curious about Mikes statement regarding GAMESPR, I would assume that to be a sprite, does the tfx1contain .tm textures in the spr directory?
  9. DrKevDog

    World Editor-3P-4tfx

    Such a tool would be very nice. The editor I am using with Gimp organizes each tile based on color, like the .wld stamspace, if I could figure out how to use and integrate the redse_.map index to the redse_.lbm bitmaps in the editor, I could move it up a notch and reuse the current ssd's to a good extent to create terrain expansion or implement the other worlds you eluded to.
  10. DrKevDog

    World Editor-3P-4tfx

    That may well be the case and nothing I can recall seeing in the files resembles a .sss. As far as concerning the build process, I believe Tfx3 evolved somewhat from the basic process. I continue to labor under the belief that the terrain world was created using a 3 level process, consistent with what is written in the .wld files. TFX2: ;World Info file for N:\3DSHAPES\TFX2\LEV\Newworld.wld ;Created With World Editor 95 V1.0 SIZE 400 400 TAGSPACE 1024 STAMPSPACE 256 TARGETSPACE 256 WORLDVIEWER e:\did\utils.win\worldv.exe SETDID n:\3dshapes\tfx2 PALETTE pd_cd TFX3: ;World Info file for q:\projects\tfx3\lev\working.wld ;Created With World Editor 95 V1.0 SIZE 400 400 TAGSPACE 1280 STAMPSPACE 256 TARGETSPACE 8276 WORLDVIEWER c:\wintools\worldv SETDID q:\projects\tfx3 PALETTE 1400pal The top level is TARGETSPACE, which in Tfx2 shares the same index with STAMPSPACE level and, therefore both are 256 (indices) wide because, IIRC, each target represents only one tile, as does each stampspace.This can be confirmed in the norway.trg file. In TFX3, they went on to develop the target Complex. The largest of which, in TFX3, is the Kings complex which includes 36 tiles. Note that the campaign.trg does not use the "colour" code to define each entry, as does Tfx2 and in which the code is consistent with the index codes in Norway.trg., but uses a completely different code list which we previously extracted from the disassembled executable. A couple years ago I did that very thing with the Tfx3 / redsea world. I organized the files into a Redsea World Directory Tree using the redsea.asc tag lines. I got side tracked and will spend some time now reviewing it. If you want a copy I can get that to you.It is interesting to me that the .asc lines are only involved with the terrain world (Static environment tiles and Static Target tiles). The ssinfo.opts involves static and non-static targets, etc..
  11. DrKevDog

    TAW terrain format

    I appreciate that you programmed it like that, it will make it much easier as I sift through the many worlds and their redundancies
  12. DrKevDog


    Brief TIALD project background: DID credits: Nevil Plura Lead Programmer Military Systems - TIALD simulator development and adaptation for EF2000. His profile: Manager/Programmer, Non-Games Applications Digital Image Design Ltd April 1991 – November 1999 (8 years 8 months) Create, manage and supply training software & custom hardware for UK defence and civil applications. Presently: Available for coaching software teams in the latest software development practices (Scrum, Agile, Lean) Wonder how he can best be contacted?
  13. DrKevDog


    This is my current list of worlds: lev\redsea.env lev\redsea.4ev lev\arcade.env lev\arcade.4ev lev\newworld.4ev lev\norway.4ev lev\iceland.lev lev\korea.lev lev\angola.lev lev\atlantic.lev lev\craig.lev lev\clouds.lev lev\faeroe.lev lev\hasbro.lev lev\libya.lev lev\martin.lev lev\nenorway.lev lev\nwnorway.lev lev\senorway.lev lev\swnorway.lev lev\norway.lev lev\wales.lev lev\world.lev lev\island.lev There is perhaps one more, name unknown. It might now be useful to categorize them according to their project affiliations. most of the lev / le2 worlds are from the tfx2 project, another group appears to be from the fws.pc (Fighter Weapons School) project and the Island lev / le2 is associated with the TIALD Military Simulation project (at least that is what the .asc file suggests). The island has some interestingly unique features. For example: In this pixel image of the Island, the 2 large white areas represent 4 world space tiles which have pointer values of "FFFF" and I suspect that has something to do with TIALD targeting systems, but needs further analysis. Five tiles code unusually for ships, but they have also not been discovered. Soon as I discover the hidden TIALD encoded military secrets that D.I.D was working on, you won't be hearing or seeing much from me
  14. DrKevDog

    What you been up to lately?

    Yep, nice video and a pretty good display of your flying skills
  15. DrKevDog


    I am using a bit of a work-around by keeping did.dat active while placing the new theater files in the lev directory knowing it will be looked at first. That way I can gain better control over the individual files in the data sets. I may have discovered a few new things. For example, I cannot recall any discussion of an "Island" theater, anyone know this one? Note: the tags are from Norway.trg and some tiles are empty. I am dusting off the old 3P-4TFx Editor to address some of these issues