***************************************************************** * NOTE: This file is out of date, see the new version at * * http://www.geocities.com/andres_james/TresView/formats.html * ***************************************************************** Hacked Trespasser File Formats Maintained by: PenguiN42 (taylok2@rpi.edu) Content mostly by (in alphabetical order :) Andres (tresutils@yahoo.com) PenguiN42 (taylok2@rpi.edu) TSOrd (charles.hughes@bigfoot.com) Last Update: 02/10/2000 Now Y2K compliant! ;) This file contains the latest known information on several of the hack-worthy file formats used in trespasser. Note: The \Trespasser\data directory is equivalent to the \Trespasser\Patch directory in the fully patched version of trespasser. ----------------- TPA -------------------- Updated: 01/26/2000 tpa -- Trespasser Audio Files Found in the \Trespasser Directory, \Demo\data directory, and the D:\data directory. Arbitrarily named (Effects, Ambient, Menu, Stream). They basically hold all the sound data (PCM or DVI/IMA ADPCM [not Microsoft ADPCM]) for the game, and caption data. TSORD - I've tested substituting the Microsoft ADPCM (which is about 75% smaller) but it doesn't work because Trespasser doesn't know how to play the data. Because of the repeating string "WBOR" throughout the file, I've named most of the elements after this "WBOR". Here are my names: First, there's a HEADER, Then, a WBOR Table (WBTable), followed by a number of WBOR Table Enteries (WTE's) Then the rest of the file is composed of WBOR Blocks (WBBlocks), which consist of a WBOR Block Header (WBH) and the WBOR Block Data (WBD). Most data is aligned to unsigned longs / intel byte order. Here are the details so far: HEADER 0x000000 Version number (Tres will only accept 0x150) 0x000004 Number of WBBlocks (UL)* 0x000008 18 00 00 00 (version number?) 0x00000C 00 00 00 00 0x000010 File size in bytes (UL) 0x000014 Number of WTE's (equal to or greater than #WBBlocks) (UL) 0x000018 BEGINNING OF WBTable *Notes from TSOrd: This (# of WBBlocks) should equal the number of WBOR table entries, sometimes it doesn't. The reason for this discrepancy is because the same sound data sometimes has two (or more?) SoundID's! There are always more WBOR Table Entries than WBOR Blocks when this happens. (SoundID's are stored in the WBOR Table Entry and not in the sound data.) My program compensates for this by writing multiple WBOR blocks - later I may work on fixing this problem properly. [To fix this problem requires naming the sound files, which will be necessary to use them properly elsewhere. I'm thinking more on this.] BEGINNING OF WBTable (Offset = 0x18, each entry = 0x38 length) There are x number of WTE's (specified in header)... o0x00 Sound ID (UL) (first one is always D9 7B A0 F0 - )* o0x04 Offset of WBBlock from beginning of file (UL) o0x08 Length of WBlock in bytes (UL) o0x0C ? Other Data (?) (usually 00 00 00 00, but sometimes not - no apparent reason, but the hex codes are interesting) o0x10 ? Other Data (?) (usually 00 00 00 00, but sometimes not - no apparent reason, but the hex codes are interesting) o0x14 'WBOR' o0x18 6E 00 00 00 o0x1C length of WBH in bytes (UL) o0x20 ADPCM Block Length o0x24 Length of WBD in bytes (UL) o0x28 Uncompressed WBOR data length (UL) o0x2C Sample Rate (UL) o0x30 Bitrate (UC) o0x31 01 -- MONO, 02 -- STEREO (UC) o0x32 00 -- PCM, 01 -- DVI/IMA ADPCM (UC) o0x33 00 o0x34 Caption Flag (0x00000000 if no captions, 0x00000024 if captions) *Notes from TSOrd: The first WBOR Table Entry points to a block of zeroes that is 16536 or 22120 bytes in length. This first entry is the default sound/caption block used whenever the TPA is missing the Sound called for. This is a special case but it is *NOT* the only case where the sound ID is duplicated between TPA files. It appears that there is one discrepancy in that normally a duplicate ID results in a duplicate sound. See the DITTO table for more information. BEGINNING OF WBlocks (Offset = 0x38 * Number of WBOR Table Entries + 0x18) Described by the WTE's WBH (info better agree with WTE info) o0x00 'WBOR' o0x04 6E 00 00 00 o0x08 length of WBH in bytes (UL) (24 unless captions) o0x0C ADPCM Block Length o0x10 Length of WBD in bytes (UL) o0x14 Uncompressed WB data length (UL) o0x18 Sample Rate (UL) o0x1C Bitrate (UC) o0x1D 01 -- MONO, 02 -- STEREO (UC) o0x1E 00 -- PCM, 01 -- DVI/IMA ADPCM (UC) o0x1F 00 o0x20 Caption Flag (0x00000000 if no captions, 0x00000024 if captions) Caption Data -- variable length (Option -- only if o0x20 == 0x00000024) o0x24 Length of Caption Data o0x28 Num of caption lines (can't be 0) o0x2C Duration to display this caption in 250ms increments (I think) o0x30 Caption text - \0 terminated string (Length of caption can be zero) (last two fields repeated for each line) WBD BEGINS FORMAT OF THE DATA IN THE WBD'S DESCRIBED IN THE HEADERS UTILITIES: TPAHack 0.2 -- extract all the data in the tpa's to wavs. MasterHack 0.1 -- extract and replace wav data. ----------------- GRF -------------------- Updated: 02/10/2000 grf -- Groff Files Found in the \Trespasser\data Directory, \Demo\data directory, and D:\data directory. Named as (level).grf. They hold all the geometry information for all the objects in the game, and some other stuff. They can be compressed (as in the game) or uncompressed (as in the demo). They are made by a custom 3dsmax plugin. Compressed GRF's are standard GZip compressed files (can uncompress with WinZip). TSOrd -- I haven't been able to recompress them using GZip - if anyone succeeds, let me know please. The basic structure of the file is the same as SCNs and SAVEGAMEs HEADER 0x00 BE BA CE 0A 0x04 File Size (UL) 0x08 # of DIRECTORY ENTRIES ? 0x0C # of name table entries 0x10 Size of NAME TABLE 0x14 Offset to NAME TABLE 0x18 00000000 0C000000 0A000000 00000000 00000000 00000000 0x30 BEGINNING OF DATA DIRECTORY DATA DIRECTORY ENTRY: o0x00 symbolHandle (formerly called Data "Tag") o0x04 00 00 00 00 o0x08 Offset to Data in File (UL) o0x0C Length of Data in File (UL) o0x10 00000000 00000000 o0x18 data type ? 01 00 00 00 -- header 02 00 00 00 -- region 04 00 00 00 -- main object block ? 08 00 00 00 -- geometry 10 00 00 00 -- mapping 20 00 00 00 -- material 00 20 00 00 -- valuetable 00 00 00 80 -- object update (used in the SCNs and SAVEGAMES) TSOrd -- For the sake of thinking, lets call this the "object update" data type I believe this is actually what these blocks do - they update the objects in the GRF file when loaded from the saved file. This should mean that only actual changeable properties can be updated - but this isn't necessarily so. o0x1C Block Handle (0x8000xxxx where xxxx is the block # from 0) DATA BLOCKS (described in DATA DIRECTORY) FORMAT OF DATA IN THE BLOCKS NOT YET HACKED -- see below for notes NAME TABLE ENTRY o0x00 symbolHandle (formerly called Data "Tag") (UL) o0x04 length of string (including terminating \0) o0x08 UL -- number of times the Handle is referenced (not including the Data directory or name table) - minimum of 1? o0x0C string (null-terminated) *The Table Entry holds more info than there are blocks in the file, with information such as the file names for images in the SWP* BLOCK NOTES (GRF specific) Note about naming the blocks: there seems to be only one .header, .region, and .valuetable per GRF. The block order seems to dictate the naming. There's a main object block (04), then after that are geometry, mapping, and materials (up to one of each) blocks which relate to the previous object block. For example, if the main object block were "Anne" ... then the next blocks could be extracted as "Anne.geometry" "Anne.mapping" and "Anne.materials" ... of course this convention is just a guess for now ;) Note: the main (named) block also points to it's mapping and geometry blocks, and the mapping points to the material block, by means of their Handles. This is the preferred method of linking the blocks together, even though the above method works most of the time. *** .header (?) 0x00 BE BA CE 0A (hehe, 0ACEBABE!) 0x04 Block number? (0x8000000F) *** .region The entries in the REGIONTABLE are actual objects in the level. They have a name, the handle of the graphic object, plus an optional reference to a VALUETABLE 'array' entry where extra initialization data is stored. HEADER 0x00 # of entries (UL) 0x04 BEGINNING OF REGION ENTRIES REGION ENTRY (44 bytes) o0x00 main Handle (of block this refers to) o0x04 symbolHandle. Name of this entry. Often same as name of main block, but if there are many instances of the main block in a level each instance here in the region table has unique name. o0x08 Position in level (3float) o0x14 Orientation/direction, as Euler angles. (3float) o0x20 Scale (float) o0x24 Valuetable entry #, or 0 if 0x28 is 0. (UL) o0x28 (UL) 0 -- No valuetable entry (use default values?) 1 -- Has valuetable entry POST-REGIONTABLE (4 bytes) o0x00 (UL) main Handle (ID) of valuetable *** OBJECT BLOCK TYPES Note: some object block names begin with a $, while others don't. What's the significance of this? Andres: ! denotes stuff/names I have got from the EXE. !? means I haven't actually checked any data to make sure it is correct. --- (main) (Object) 0x00 symbolHandle 0x04 geometryHandle 0x08 mappingHandle 0x0c physicsHandle (always zero) 0x10 AIHandle (always zero) 0x14 soundHandle (always zero) 0x18 specialHandle (always zero) --- .mapping If the geometry is type2, the mapping contains only the material handle as the texture info is in the geometry block. type1 geometry has the full texture info here in the mapping. 0x00 materialHandle 0x04 textureVertexCount ! 0x08 textureFaceCount ! 0x0c array (float)[textureVertexCount*2] ! (Texture coords) 0x?? array (UL) [textureFaceCount*3] ! (face vertex indicies) These index into the .geometry vertex array (check) 0x?? array (UL) [textureFaceCount] ! These index into the .material textureMapHandleList (check) --- .material Contains info on which textures, transparenct and bump maps are used by this object. Also has some lighting parameters. Size Description (ULs) 1 materialCount = N N textureMapHandleList, symbolHandles (TAGs). N opacityMapHandleList (often 0x05489c90 = empty string "") ! N bumpmapHandleList 3*N materialColorList (often 0x00000080) ! 1 ambientLighting !? 1 diffuseLighting !? 1 specularLighting !? 1 opacity !? 1 bumpiness !? The symbolHandle (TAGs) are all to strings of the form "Map\LevelName\ImageName.bmp" Most ImageNames seem to be post-fixed with either "t2" or "b8". At a guess the t2's are normal textures and the b8's are bumpmapped ones. If so, the second texture list is the same as the first list, but with normal textures instead of bumpmapped textures. (Detail settings?) Some Image Names are also post-fixed with o8, and some aren't post-fixed at all. Can't yet find if there's a relation between the post-fix and the symbolHandle (TAG) for that texture. These strings are mapped to the TexIDs in the PIDs using an obscure hashing technique that still isn't completely understood. TSOrd - materials are all multiples of 24 bytes, minimum 48 bytes. --- .geometry Blocks of type1 are mostly 0x3b8 long and are cubes. (Triggers and physics bounding boxes?) There are some diamonds and other shapes. Blocks of type2 can be much larger, and include texture coords. All visible geometry might be this type. Type1 seem to have a large corresponding .mapping that contains texture info. Type2 contain their own texture info, so the .mapping is only 4 bytes long. This difference in .mapping size may be a consistent method to distinguish the two types of geometry type1: HEADER(10 dwords) 0x00 pivotOffset (12bytes) ! ? First 4 bytes seem to be the materialHandle or 0 if no .material 0x0c A vertex count (UL) ! # vertices 0x10 B face count (UL) ! # triangles 0x14 C vertex normal count (UL) ! # triangle vertex normals (C=3*B) 0x18 D wrap vertex count (UL) ! # coords. bbox? 0x1c default color (12bytes) ! 0x28 Start of arrays The header is followed by five arrays in the following order: VERTICIES (A x 3floats) Array of 3 floats per vertex. FACES (B x 3 ULs) Array of 3 ints per triangle. These are indexes into the VERTICIES FACE NORMALS (B x 3floats) Array of 3 floats per triangle, the normal of the triangle. VERTEX NORMALS (C x 3floats) Array of 9 floats per triangle (a 3float normal for each vertex). The three vectors for a triangle are equal to triangle normal if it is flat (like a box), or may be different if it's meant to be curved (like a cyliner) WRAP VERTICES (D x 3floats) Array of 3floats. Often there are 8, so they seem like a bounding box. But sometimes there are more than 8. type2: HEADER(11 dwords) 0x00 (UL) materialHandle or 0 if no .material 0x04 (UL) ? 0x08 (UL) ? 0x0c (12byte) !? 0x18 A # vertices 0x1c B # textured normals = 3*number of triangles 0x20 C # ULs in TRIANGLE list (= 3*# triangles + some extra) 0x24 D # coords. bbox? 0x28 E # of texture info entries This header is also followed by five arrays. The verticies and bbox are the same as type1, but the other three are different: VERTICIES (A x 3floats) Array of 3 floats per vertex. TEXTURED NORMALS (B 32byte entries) Each entry points to a vertex, and has a normal & texture stuff. 0x00 UL, index into VERTICIES 0x04 3floats, vertex normal 0x10 2floats, texture coords 0x18 2ULs, 0x00000001 0x00000000 always? TRIANGLES (C ULs, arranged into two parts) The first part is B ULs long. It is a list defining B/3 triangles (each three ULs indexing into the TEXTURED NORMAL table). Second part has (C-B) ULs. These also index into the TEXTURED NORMAL table. This list is usually covers the TNs in ascending order, however sometimes skips an index. I think that the ones that are skipped are never used as part of a triangle. The TEXTURE INFO entries refer to this list. TEXTURE INFO (E x 40bytes) 0x00 UL NUM verticies 0x04 UL OFFSet into TRIANGLES list 0x08 3float normal, (of polygon(s) ) 0x14 float ??? 0x18 UL texture index (into .mapping texture list) 0x1c UL ??? 0x20 ? 0x00000000 always? 0x24 float ??? This seems back to front, though I am just guessing at how it is used. Instead of directly getting the texture # for a triangle, you look here to get the tex#, then get NUM indicies starting at position OFFS in the TRIANGLES table, and apply the tex# to the TEXTURED NORMAL referred by the indicies we just got. !!! (i hope that makes sense) So it looks like they are specifying a texture ID per vertex, which is strange as all three verticies in a triangle must refer to the same texture. (ie why not define one texture ID per triangle?) Check this. BBOX (D x 3floats) Array of 3floats. Often there are 8, so they seem like a bounding box. But sometimes there are more than 8. *** .valuetable The VALUETABLE stores extra initialization info for objects in a level. The entries are referred to by the REGIONTABLE entries. Valutable (0 is the beginning of the valuetable block) 0x00 00 00 00 00 00 00 0x06 # of strings in StringTable (UL) 0x0A 00 00 00 00 00 00 0x10 # of strings in StringTable (UL) 0x14 STRINGTABLE (n entries) 0xxx ASSEMBLY HEADER 0xxx ASSEMBLY (n entries) STRINGTABLE ENTRY o0x00 Null-terminated String (including the terminating 00) o0xxx Number of this string (from 0) (UL) o0xxx Number of times this string occurs in ASSEMBLY (UL) ASSEMBLY HEADER o0x00 00 00 00 00 00 o0x05 # of entries? (UL) o0x09 00 00 00 00 00 o0x0E # of entries? (UL) o0x13 BEGINNING OF ASSEMBLY? VALUETABLE ENTRY 0x00 Entry type (US) 0x101 -- Boolean 0x103 -- Integer 0x104 -- Float 0x105 -- String 0x106 -- Array 0x02 00 0x03 Entry # (UL) 0x07 01 00 00 00 0x0b Entry name, index into STRINGTABLE. (UL) 0x0f Number of times Entry name has been used so far [AJ: Is this important for execution, or just to help the editor delete unused strings or something?] 0x13 00 00 00 00 0x17 00 00 00 00 0x1b Entry data, depends on Entry type Boolean -- Unsigned char, 0=false, 1=true (1 byte) Integer -- (Unsigned?) long (4 bytes) Float -- float (4 bytes) String -- zero terminated ASCII (L bytes) Array -- N = Array size (UL), followed by 2*N UL's. (4+8*N bytes) [Every second UL seems to always be 0x01?] 0xXX Entry # again (UL) 0xXX 01 00 00 00 [AJ: The array entries store a list of other entry numbers. These entries form a group describing initialization data for a class instance. The REGIONTABLE entries will thus point to an array type entry] UTILITIES: GRFHack 0.10 -- extracts all the blocks from GRFs, SCNs, and SAVEGAMES. GeomExt 0.12 -- extracts .geometry as 3ds files. Does most textures. MasterHack 0.1 -- can sorta change savegame positions... ----------------- SCN -------------------- Updated: 1/23/2000 scn -- Scene Files Found in the \Trespasser\data Directory, \Demo\data directory, and D:\data directory. Named as (level).scn. They hold, in a partitioned data format, similar to a BSP Tree, all the information of the placement and state of the objects in the game. Save Game files seem to be a modified version of this format. These files have the same data structure shell as the GRF files. See the GRF entry for the basic file structure *Notes from Andres: The block IDs (Handles) don't seem to be used in SCNs, as the order of the blocks can change but the IDs don't. Also the tag (symbolHandle) for a block can change. However the NAME of a block in the SCN matches the name of the equivilant block in the savegame, so that can be used to track the position of an object in a savegame. I don't think the names change, though perhaps they are dynamic state info and I just looked at stuff that hadn't moved. Aha: for the blocks that have hex numbers in the name table, those hex numbers are hashes of data names in the GRF name table, similar to Texture IDs. How intuitive! :P BLOCK NOTES (SCN Specific) SCNs contain a Header, Partitions, Hierarchy, TerrainHierarchy, and TriggerHierarchy, along with the Data blocks, named with a hexadecimal string. "Header" o0x00 -- length of null terminated string o0x04 -- beginning of string data (path to and name of GRF file on original machine) The rest of the data in the header is unknown (usually mostly 00) *** "Partitions" HEADER 0x00 (byte) ??? 0x01 Start of PARTITION ENTRIES Doesn't seem to say how many entries there are...but the size of the partitions block is exactly 28*n+1 bytes. PARTITION ENTRY (28 bytes) 0x00 (3float). Sometimes seem to match (part of) the position in the 36 byte entries ??? 0x0c (3float) ??? 0x18 (UL) ??? *** "*Hierarchy" I see some patterns in the Hierarchy type blocks, but can't get anything solid yet. Perhaps they're 3d vectors or points (it seems divisible by 3 longs). *** The rest of the blocks have a string name that looks hexadecimal, presumably holding the state information for an object in the level. They seem to relate to the grf.region information The great majority of them are 36 bytes long, though a few specific n header. SCN ENTRY (36/44bytes) 0x00 position in level (3float) 0x0c (3float) looks normalized. heading? 0x18 (float) ??? 0x1c (float) scale 0x20 (UL) ??? 0x24 (UL) ??? 0x28 (UL) ??? UTILITIES: GRFHack 0.10 -- extracts all the blocks from GRFs, SCNs, and SAVEGAMES. MasterHack 0.1 -- can sorta change savegame positions... ----------------- SWP -------------------- Updated: 02/04/2000 swp -- Uncompressed Swap Files Found in the \Trespasser Directory, and \Demo\data directory. Uncompressed from the .spz files in the D:\data directory. Named as (level)-130.swp. They hold all the texture maps, mip maps, and bumpmaps used in the game. Texture maps, at least, are 8-bit palleted BMP-type format. The indexes to the SWP's are in the PID files. If the SWP doesn't exist for a level, or if the 'modified' time/date stamp on the SWP doesn't match the modified time/date stamp on the SPZ, then trespasser uncompresses the SPZ on to your hard drive to run the level on load-time (this is reflected in the "Level File Copy" progress bar. Trespasser will overwrite the apparently tampered-with SWP if it's time/date is different. Using a file date modification utility gets around this. The SWP data consists of a series of Bitmap BLOCKS. These contain raw bitmap data. In each block is a bunch of textures. The PID file tells you the width of the BLOCK, and the (smaller) width of the texture it's pointing to. There is one PID entry per texture, so several per block. Non-bumpmapped textures are 8-bit paletted bitmap data Bumpmapped textures are 16-bit and interlaced like so: bits 0-9 bumpmap value bits 0-3 phi: The latitude, from 0 to 90 deg. bits 4-9 theta: The longitude, from 0 to 360 deg bits 10-15 color index value (max 64 colors) THE DATA IN THE SWP FILES IS DESCRIBED IN THE CORRESPONDING PID FILE. IT IS PRETTY MUCH RAW BMP DATA. UTILITIES: SWPExt 0.35 -- extracts BMPs to all pictures. Can separately extract raw bumpmap data (with header) Can skip mipmaps. Can name some files SWPAdd 0.22 -- can replace a single texture block can replace bup data does mipmaps BumpConvert 0.01 -- converts bups to heightmaps ----------------- SPZ -------------------- Updated: 01/22/2000 spz -- Compressed SWP Files Found in the D:\data directory. They seem to be compressed with either a modified gzip or zip, with a stripped down header. However, the details of the compression structure are currently unknown. As mentioned in the SWP block above, if the SWP doesn't exist for a level, or if the 'modified' time/date stamp on the SWP doesn't match the modified time/date stamp on the SPZ, then trespasser uncompresses the SPZ on to your hard drive to run the level on load-time (this is reflected in the "Level File Copy" progress bar. Trespasser will overwrite the apparently tampered-with SWP if it's time/date is different. Using a file date modification utility gets around this. Also, if the game determines it doesn't need the data in the SPZ (ie SWP already exists and has the correct date/time stamp), then it doesn't even look at the data within the SPZ -- any non-zero length "dummy SPZ" will satisfy the engine. The Demo engine does not use SPZs. FORMAT NOT YET HACKED. ----------------- PID -------------------- Updated: 02/02/2000 pid -- Picture Index Files Found in the \Demo\data directory and D:\data directory. Named as (level)-130.pid. These files are indexes to the appropriate .swp files. They also seem to serve as a kind of copy protection since, in the commercial version, they are *always* loaded off the CD, and not the HD. This could pose problems for making 3rd party levels unless our level runs with the Demo exe, or we can crack the commercial exes to allow 3rd party levels. The structure is this: a short HEADER, then a bunch of PALETTE BLOCKS which consist of a PALETTE BLOCK HEADER, and the PALETTE DATA, then a bunch of TABLE ENTRIES. HEADER 0x00 Version, latest verion = 0x130. (UL) 0x04 10 00 00 00 0x08 offset to TABLE (UL) 0x0C number of TABLE ENTRIES (UL) 0x10 20 00 00 00 - length of this header? 0x14 Number of PALETTE BLOCKs (UL) 0x18 00 00 60 00 0x1C varies (UL?) 0x20 beginning of PALETTE BLOCKS PALETTE BLOCK HEADER o0x00 Length of this palette block (including header) o0x04 Number of palette entries in this block o0x08 varies (UL?) o0x0C PALETTE DATA (BMP-style) ..... o0xxx footer dword thing (last 4 bytes) ... (?) TSOrd notes: The count of Palette entries must be the number of palettes based on one long per palette entry (length = 16 + number * 4) TABLE ENTRY o0x00 length of this entry (usually 56) o0x04 offset into SWP o0x08 width of texture map in pixels o0x0C height in pixels o0x10 width of containing BMP in bytes o0x14 bit depth 8 -- SWP value = palette index 16 -- bumpmapped. SWP value = bits 0-9 bumpmap data, unknown bits 10-15 palette index NOTE: Bumpmapped textures are limited to 64 colors o0x18 ? (Some sort of Group ID?) (looks like a 3 byte code, lots of repeats) o0x1C transparency flags 0 -- no transparency 1 -- ? (occurs sometimes when Group ID is ffffffff) 8 -- Palette index 0 is transparent, appears as pure blue TSOrd - NOTE: Sometimes the transparent color is pure green. o0x20 image type 0 -- indexed palette (bitdepth=8) 1 -- curved bumpmap? (bitdepth=16). (occurs sometimes when Group ID is ffffffff) 16 -- indexed palette with bumpmap (bitdepth=16) o0x24 Always 00 00 00 00, except for 1 entry per PID which is 0x02000000. This corresponds to a grey 8x8 texture in TestScene. Strange! o0x28 Palette Block Index (a number from 0 to # of palette blocks - 1) (or FFFFFFFF) o0x2C ? A single repeated value, seems to different in each PID. Except in the TestScene where there are about 13 different values. o0x30 Texture ID, hash of texture name in GRF nametable -- same for all mips. However there seem to be alot more textures in the PID than bitmap names in the GRF. o0x34 Mipmap data. If 00000000, then is the original (non mipped) texture. Otherwise: bits 0-7 same as width of mipmap bits 8-19 height of mipmap * 4 bits 20-31 ? But is the same for all images/mipmaps with the same palette. TSOrd - This isn't true. These 12 bits change with no relation to the pallete. I'm not sure what they're used for. UTILITIES: SWPExt 0.35 -- extracts BMPs to all pictures. Can separately extract raw bumpmap data. Can skip mipmaps. Can name some files SWPAdd 0.22 -- can replace a single texture block can replace bup data does mipmaps ----------------- WTD -------------------- Updated: 02/01/2000 wtd -- World Terrain Data Files Found in the \Trespasser\data Directory, \Demo\data directory, and D:\data directory. Named as (level).wtd. This format seems to hold the geometry and maybe some texture data for the Terrain of each level in the game. It may be stored as some kind of wavelet compression. It may also be compressed similar to how GRF and SPZ files are. Not much is known about this format yet. One can interchange the wtd files for some levels in the game and get some interesting results. FORMAT NOT YET HACKED. ----------------- SMK -------------------- Updated: 12/30/1998 smk -- Smacker Video Files Found in the \Demo\data\menu directory and D:\data\menu directory. Arbitrarily named. Contains the movies used at the beginning and end of trespasser. This is a standardized format rather than a DreamWorks Proprietary format -- Mechwarrior 2 also uses SMK files. SMACKW32.DLL holds the routines to play them back, but we don't care about that :) ... I got a free SMK compressor from www.radgametools.com ... cool stuff. UTILITIES: Smacker Utilities, available for free download. ----------------- DDF -------------------- Updated: 1/21/2000 Figure these out at some point, they look easy. Text files which script the appearance and actions of buttons and windows and such. Basically the GUI layer of the game. Found in the \Demo\data\menu, D:\data\menu and Trespasser\menu directories.