DrKevDog

Members
  • Content count

    1,215
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrKevDog

  • Rank
    Colonel
  1. 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.
  2. 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?
  3. Gonna need some extra time to get both versions analyzed. Perfect timing...Thanks!
  4. 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:
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 1. The C4 objective is only the primary objective for the first 10 hours of the campaign and required damage is only 20%. Attacking EWR stations does blind the enemy and yet, the first priority would be to focus on the primary targets. After the 10 hours expires the target class changes to airforce which means all the "outside" attacks, during the C4 targeting period, should be centered around clearing lanes for Strikes to access enemy airforce targets. 11. TAW does not have a dynamic resource management code of any significance, therefore, if the game gives you F-22s: take-em.
  10. The 0028 opcode is more interesting than at first. It has me rooting around in the executable and wishing there was more known about the structure and format of the executable. format: 0028 <unknown><unknown> Unknown #1 appears to set the distance at which action is initiated Unknown #2 is the offset to the routine in bytes (-2B) The unusual thing about the unknown #2 in the 0028 instruction is that it seems to disregard .3 file headers and footers and treats the executable like a container. It can execute the shadows routine of one .3 file when called from another, simply by adding a proper 0028 line to the recipient file. An array of 0028's can do some interesting things. Below is an image of Hangl_90.3 with its file-coded shadow in the back but also with the shadow contained in the Hangs90.3 file-code in the front. It's like I have now acquired the ability to bend light, bi-directionally
  11. 100 Bitcoins deserves the man who persevered to analyze the timeline all the way back to F29-Retaliator. My hats off to you I'm still working on opcodes 0028 and 0029, hopefully some progress by next post.
  12. I am following your archeological ventures with good interest. One of my concerns with the undocumented opcodes is that, despite reasonable efforts to define their function, without a formal game example / model, the definitions remain unprovable and mere speculation. That similar functions are grouped together is helpful. I'm currently working on undocumented opcodes 0028 and 0029. Like 0026 and 0027, we can assume some similar function. 0027 <threshold> <offset> If the object’s distance from the viewer is above or equals <threshold>, jump <offset> - 2 bytes. Used to fade details, e.g. shadows, with distance. This is what I have discovered for 0028: format: 0028 <unknown><unknown> Many of the values I plugged in caused a program fault but a few caused a division overflow. That led to an assumption that, because a division overflow is not very common, I could work with divisional increments, so I began playing around with some integers and found a pair that resulted in the following: Believe it or not, that shadow is cast from the windsock (awind.3) by simply adding 002800C51770 to the front of the bytecode. It seems 0028 handles horizontal shadow casting while 0029 handles vertical shadows. I still get some instability and the file modified will cast shadows off of any nearby object at times and other times is stable. The values I used for the unknowns were an educated guess and I am still trying to know what those unknowns really are.
  13. Very Interesting.
  14. LOL! I have thought of that at least a hundred times. The idea of it simply being useless code is, IMHO, not only unpleasant but, more disturbing, currently unprovable
  15. The header format looks identical. Eluding to the comment you made about the increasing complexity of the opcodes as TFX evolved, I wonder if the Robocop executable would make for easier work finding where the .3 handling could be located and give some clues on how to find it in the later programs?