In analyzing the way TAW controls and limits cloud levels the following system of global texture control was discovered and may offer some insight into how the control systems work. I will refer to that system as the global texture system for reasons that will soon be apparent.
Global textures system activation is a method used to provide textures to the game world environment on a global wholesale scale. The standard ordering of textures for 3D objects in the TAW environment is generally through either the .3 files use of file header textures where the name of the texture file to be used is declared in the file header and accessed directly from the TM folders – or – by the .3 file utilizing the texture index files (redxxxx.ini), to initialize the textures. If the initialization file is not accessible then the global textures system can provide textures for the world environment for that T.O.D..
It appears that the global texture system is not active in TAW by default and must be manually configured.
The standard order of function of the in-game texture acquisition process in TAW involves first, the executable (f22.dat) accessing the .txt file (redxxxx.txt) which, in turn, accesses the .ini file (redxxxx.ini). The executable initiates the process at game loading by accessing two .txt files (red0800.txt and red1000.txt) which are loaded at the start of the game:
DGROUP:0063199C aEnteringGamema db 'Entering GameMain.',0Ah,0 ; DATA XREF: sub_44DF7C+C o DGROUP:006319B0 aNoMouseDriverP db 'No mouse driver present.',0 ; DATA XREF: sub_44DF7C+42 o DGROUP:006319C9 align 4 DGROUP:006319CC aRed1000 db 'red1000',0 ; DATA XREF: sub_44DF7C+59 o DGROUP:006319CC ; sub_44DF7C+68 o … DGROUP:006319D4 aRed0800 db 'red0800',0 ; DATA XREF: sub_44DF7C:loc_44E026 o DGROUP:006319D4 ; sub_4525C8+F0 o DGROUP:006319DC aLev db '\lev\',0 ; DATA XREF: sub_44DF7C+BD o
If after the initial game loading, a T.O.D. other than 08:00 or 10:00 is requested by the player, the specific redxxxx.txt file must then be loaded from the levels (lev) folder. The redxxxx.txt file will then point to the specific redxxxx.ini file to be used at that requested T.O.D., and which is declared in the top of its file content in the init3d lines: init3d_file redxxxx.ini. The redxxxx.ini file contains the texture indexes and points to the T.O.D. specific TM file where the needed textures are stored.
If for some reason the game cannot find or access the .ini file it will begin to request the global textures (which are not loaded at game start). There are at least eight global textures known at this entry:
DGROUP:0064C234 aGlobaltextures db '[globaltextures]',0Ah ; DATA XREF: DGROUP:off_6DB7EC o DGROUP:0064C234 db '1=global_1',0Ah DGROUP:0064C234 db '2=global_2',0Ah DGROUP:0064C234 db '3=global_3',0Ah DGROUP:0064C234 db '4=global_4',0Ah DGROUP:0064C234 db '5=global_5',0Ah DGROUP:0064C234 db '6=global_6',0Ah DGROUP:0064C234 db '7=global_7',0Ah DGROUP:0064C234 db '8=global_8',0Ah,0 DGROUP:0064C29E align 10h
The initial tests indicate that the 8 global_x textures are assigned to texture the objects just as the normal textures in index positions 1–8 would do.
[dir] TM=red1000 [globaltextures] 1=cam3_9 2=cam3_10 3=plane_21 4=material 5=mattdead 6=mob_5 7=fx_4 8=cam3_22
METHODOLOGY: Initially we edited out one of the redxxxx.ini files and ran TAW at the same T.O.D. as the deactivated .ini file. This forces TAW to call an error :
init3d: couldn't find '.\red1600\global_1.tm'
Through a series of trial and error runs we determined that the game will run the global texture system to accommodate for the inability to access one or more initialization files. The game will substitute global_1.tm, in the default folder, for the TM at index position #1 in the inaccessible redxxx.ini (which is always cam3_9.tm). Initially we substituted newly created red or green marker TM files for global_1 thru 8 and placed them in the default TM folder. Subsequently it was determined that all 8 of the above first 8 indexed
TM textures (cam3_9, cam3_10, etc) have 7 analogous copies in the extracted file archive set. Being that there are only 6 redxxxx TM directories, it seemed logical that one of the seven extracted should be used for the global_x texture file. It was also noticed that the first of the 7 analog files (lowest noname number value) was subtly but uniquely different than its 6 peers, therefore it was decided to use the first extracted of each type as the global_x file. These files have some unusually curious effects in-game.
Currently red1000 is being used as the default TM folder, housing the eight new global_x textures. Only red1000.ini remains activated in the game, with the other nine redxxxx.ini files edited out. Using this system, all T.O.D. missions and campaigns are fully functional and exhibit normal evolving T.O.D. environment changes despite their sharing the exact same TM texture files.
The true purpose of this system remains speculative, however, there is some evidence that perhaps it is related to the unused file noname8319 which is an extracted but unused redxxxx.ini file suggesting hardware process over software.
It is hoped that exploring the controls on this system will grant us further insight into how the cloud system is controlled and perhaps give HF a way to implement a greater number and diversity of cloud cover types.
Below is a simple graphic view of what happens by using alternating red and green TM markers for the files global_1.tm thru global_8.tm placed in the red1000 TM folder and simply editing out red1600.ini then playing a mission at 16:00:
With the recently identified unused-extracted TM textures, coupled with applications using this global textures system, more useful information can be gained regarding how to further understand the workings of this simulation 😎
