DrKevDog

Members
  • Content count

    1,224
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrKevDog

  • Rank
    Colonel
  1. 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.
  2. 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..
  3. I appreciate that you programmed it like that, it will make it much easier as I sift through the many worlds and their redundancies
  4. 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?
  5. 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
  6. Yep, nice video and a pretty good display of your flying skills
  7. 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
  8. I do not think, at this early stage in testing, that the suspension should be changed, landings now require more attention and yet there is still a considerable room for errors. I need to fly more fuel related sorties to test the new consumption coding, but I do know I have had to park the plane in a field and walk back to base on quite a few occasions thus far Not to mention the new nagging voice that chimes in rather quickly and incessantly It makes sense to wait for a common format. I will continue extracting and grouping what I can.
  9. This version has a lot of improvements. I find it more challenging to takeoff and land and the virtual perception of power and thrust of the F22 are heightened. Much to explore, however, I am currently focused on the new Ef2k hidden levels project There is a significant difference between allowing the did.dat to control the process as compared to manually placing the specific files in the lev directory and using game.cfg to call the various theaters via the new TFXplorer. I would add Faeroe and Clouds to the list of levels which can be accessed now. This is Korea with did.dat active: This is Korea manually: The selection of theaters is implemented by using 3 files: .lev, .le2 and .dat. Korea has 6 sets of files, Libya has 8. 5 of the Korea level files (file1) are identical and one is unique, I wonder if they are somehow involved in time of day determinations similar to how tfx3 swaps TM directories for time of day. One question is why the program is stacking multiple tiles at various locations on the grid. I am categorizing and grouping the theater files into file sets and maybe that will provide some additional direction. Does anyone know what Norway.4evz, .ascz and datz do for level determination?
  10. Gonna need some extra time to get both versions analyzed. Perfect timing...Thanks!
  11. Wow again! Much different. Here is my update: X TOD Mode 0043 VALUE bit fields 0 00:00 NO MOON AT NIGHT 0000 00000000 00000000 1 08:00 RED0800 0001 00000000 00000001 2 10:00 RED1000 0003 00000000 00000011 3 12:00 RED1200 0007 00000000 00000111 4 14:00 RED1400 000F 00000000 00001111 5 16:00 RED1600 001F 00000000 00011111 6 18:00 RED1800 003F 00000000 00111111 7 20:00 RED2000 007F 00000000 01111111 8 22:00 MOONLIT NIGHT 00FF 00000000 11111111 9 06:00 RED0600 01FF 00000001 11111111 Tfx has evolved the T.O.D. system and shadow implementation over its successive releases. EXAMPLE: Shadow.3 (tfx2) FFF30BB8000000007FFF000000000000EA840000 0002000300030000000000000000000E034603460346000000000000001D 0030000A 00620000FF79FFCE0087 0066FF10 00650032 006600F0 0064010E 0065FFCE 0066FF10 00650032 0064FF19 00660000 00640060 00660000 00640060 00660000 0065FFC8 0064FFA0 00660000 0064FFA0 0067FFF1FFF2 006600F0 006400DE 0066FF10 0067FF4FFFF6 006600F0 00640084 0066FF10 0063FFDC005000F0 0068FF8EFF5B 006400A8 0061001D0000 001B000B000F001B00030004001C 001B000B000F001B000900020003 001B000B000F001C00040007000D 001A000B000F000800010002 001B000B000F0008001100120001 001B000B000F0012001100100016 001B000B000F000F001900160010 001B000B000F000F000E00150019 001B000B000F0015000E000C0006 001A000B000F0006000C0007 001B000B000F0003000200010000 001B000B000F0004000500060007 001B000B000F0000000100120013 001B000B000F0006000500140015 001B000B000F0013001200160017 001B000B000F0015001400180019 001B000B000F0016001900180017 001A000B000F0000001A0003 001A000B000F001A00000013 001A000B000F001A00130017 001A000B000F0018001A0017 001A000B000F001A00180014 001A000B000F0005001A0014 001A000B000F001A00050004 001B000C00B0001B00030004001C 001B000C00B0001B000900020003 001B000C00B0001C00040007000D 001B000C00B0001B00030004001C 001B000C00B0001B000900020003 001B000C00B0001C00040007000D 001A000C00B0000800010002 001B000C00B00008001100120001 001B000C00B00012001100100016 001B000C00B0000F001900160010 001B000C00B0000F000E00150019 001B000C00B00015000E000C0006 001A000C00B00006000C0007 001B000C00B00003000200010000 001B000C00B00004000500060007 001B000C00B00000000100120013 001B000C00B00006000500140015 001B000C00B00013001200160017 001B000C00B00015001400180019 001B000C00B00016001900180017 001A000C00B00000001A0003 001A000C00B0001A00000013 001A000C00B0001A00130017 001A000C00B00018001A0017 001A000C00B0001A00180014 001A000C00B00005001A0014 001A000C00B0001A00050004 0000 FFFF 002000200020 Shadow.3 (tfx3): FF8B3E80000000007FFF00000000000000000000 0002000300030000000000000000000E039C039C039C0000000000000006 002701900386 002701880138 002701800128 002701780118 002701700108 0027016800F8 0027016000E8 0027015800D8 0027015000C8 0027014800B8 0027014000A8 002701380098 002701300088 002701280078 002701200068 002701180058 002701100048 002701080038 002701000028 002700F80018 002700F00008 000700C6 0000 0098FFFF 000700BC 0000 0098FFFE 000700B2 0000 0098FFFD 000700A8 0000 0098FFFC 0007009E 0000 0098FFFB 00070094 0000 0098FFFA 0007008A 0000 0098FFF9 00070080 0000 0098FFF8 00070076 0000 0098FFF7 0007006C 0000 0098FFF6 00070062 0000 0098FFF5 00070058 0000 0098FFF4 0007004E 0000 0098FFF3 00070044 0000 0098FFF2 0007003A 0000 0098FFF1 00070030 0000 0098FFF0 00070026 0000 0098FFEF 0007001C 0000 0098FFEE 00070012 0000 0098FFED 00070008 0000 0098FFEC 00620000000500000005 0066FFF6 0064FFF6 0066000A 006100040000 004200000224 00420001021E 004301FF0038 004300FF0212 0043007F020C 0043003F018E 0043001F014C 0043000F010A 0043000700C8 004300030086 004300010044 000701E4 0000 00620004FF8B0000FFFB 0066000A 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500030002 000701A8 0000 00620004FFC70000FFFB 0066000A 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500030002 0007016C 0000 00620004FFDD0000FFFB 0066000A 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500030002 00070130 0000 00620004FFEA0000FFFB 0066000A 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500030002 000700F4 0000 00620004001600000005 0066FFF6 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500010000 000700B8 0000 00620004002300000005 0066FFF6 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500010000 0007007C 0000 00620004003900000005 0066FFF6 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500010000 00070040 0000 00620004007500000005 0066FFF6 006100020004 00470006000400000040003F0040003F007F0000007F 008800040004000500010000 00070004 0000 0000 FFFF 002000200020 * Note how tfx3 0042 opcode has a 0000 time value, used in company with 0043. Tfx3 also added the 00A1 / 00A2 shadow format upgrade, however, these were only used, exclusively, for the highest LOD F22 models. The 0043 opcode control over shadow rendering is fairly straight forward, but they don’t use it in that way. For example, if you check the very last vertex/ uv-mapping block in each of the building shadow blocks, you will see, at least in all the models I checked, it is never rendered. I suspect It is the block for the 00:00 shadow (value = 00) which reuses the 18:00 shadow (3F), ie. RED1800(3F) is reused for RED2000 (7F), MOONLIT NIGHT (FF) and NO MOON AT NIGHT (00). I believe the unused block, at the end of the texture mapping section, is written specifically for the 00:00 / NO MOON AT NIGHT (00) shadow. (still working on the bit mask calculations) Note that time values 00, 7F and FF are not included in the basic, static object files 0043 tree: Build.3: 004301ff002e ; 004301ff0028 0043003f0172 0043001f0134 0043000f00f6 0043000700b8 00430003007a 00430001003c 0000 I believe they tried to save some cycles, in shadow rendering, by modifications reusing the RED1800 shadow, with the 0043 shadowing process. They appear to be simply reusing the RED1800 shadow for 20:00, 22:00 and 00:00. Point of information: Previous difficulty with finding an in-game “NO MOON AT NIGHT” scenario, on which to test, is resolved by using the tfx3 diagnostics; it even prints a log, in the CCCW MFD, of the T.O.D. being used:
  12. Interesting comment on the EF2000 / TAW difference. The tests I did on 0043 in ref_2.3 gave me double shadows. Ref_2 .3 might not be a good test model because it handles the shadows at 0043007F separate from all the others, for some reason. I'm going to retest and redo my calculations and post anything of significance.
  13. Update on undocumented opcodes: I seriously over-analyzed 0028 and 0029, they are the same as codes 0026 / 0027 except with a call instead of a jump. I was able to get a better analysis when i substituted them in ref_2.3 for 0043. Code 0043 is a Time of Day opcode and I seem to have discovered two additional, undocumented T.O.D. codes: 0044 and 0046. This analysis is greatly facilitated by the TAW Diagnostics, which has a feature for advancing time skip hour-by-hour or minute-by-minute. The previous work on T.O.D. codes lays out some of the bit mask data which is very helpful, thanks. Using the time skip diagnostics seems to provide some empirical data to suggest there may be a number of different bitwise operations used in this group of opcodes. if there have been any updates on the 003f thru 0046 operations, especially regarding less commonly used operations like "bit flipping", please post.
  14. Speaking of .3 headers, IIRC, not until tfx3 did they introduce the upgrade-transition from the class 00 shape files to 83. The 83 files are much easier to work with so I am trying to find an easy conversion process. It seems that the main factors are the presence and number of LOD's, and the presence or absence of a header texture and its length, don't recall if render order is a factor also, but didn't you work this all out at some time in the past?
  15. SPECULATION ALERT! I am speculating that 0028 is a different type of instruction/opcode than we have been studying before, which is perhaps why it is not found in any of the game files. It seems to be a practical opcode for use during the development phase. 0028 can render a wide range of routines and subroutines. It would be useful to the graphics artists who were working on the 3d models. Let’s say, for example, an artist is working on the visuals for the damage states of the Luxor tile, and lets say they are working on the lux_radr.3 model and would like to visualize the various LOD and damage state models in-game. They could use 0028 to simultaneously render the various damage state models, in-game, for inspection and potential modifications. Simply place the 0028, or an array of such, in the lux_radr.3 file and configure it so that the second operand word calls the specific damage model subroutine and the first operand word defines the distances at which the called model will be rendered. The specific model can be further manipulated, for analysis, by placing modification codes, such as 0030 (scale) ahead of the 0028 instruction. 0028002F15EC In this example I have set the distance so that only the undamaged model is visible beyond distance 002F. From distance 0 to 2F I also call the subroutine for damage state 1: 003000020028002F15EC This example is identical to the above, except I scaled the damage model up to unmask it completely.