| 04-18-2002, 10:08 PM | #1 |
Last update: 09/05/2002 You'll find here a lot about the formats of all these files packed in the w3m. (This is an update of my previous HowTo) OK Let's go! :D 1) Things you need to know first to mod a map! 1a) You environment You'll need Warcraft III beta installed let's say in "c:\war3beta\". I'll talk about files of War3beta here, some files format can vary depending which version you're using, you may have to figure out some differences in the file formats. If your installation is clean, you should have these files: (of course, there are other files in there but we need these) in your "c:\war3beta\": - war3beta.mpq - War3BetaPatch.mpq and in your "c:\war3beta\maps\beta": - (4)Lost Temple.w3m - (4)Tranquil Paths.w3m - (6)Dark Forest.w3m - (6)Gnoll Wood.w3m - (8)Battleground.w3m - (8)Golems in the Mist.w3m - (12)Divide and Conquer.w3m All these files can be opened with a MPQ editor. You'll need one. I suggest WinMPQ, you can get it here: http://shadowflare.ancillaediting.ne...ad.html#WinMPQ Read the documentation and installation notes. 1b) Warcraft 3 Files - MPQ Files MPQ are like "zip" or "rar" files as they contain a directory structure with compressed files. When it's looking for a file, Warcraft III looks first in the "real" directories (the one you see in Windows Explorer), then in the last patch mpq (War3BetaPatch.mpq) and finally in the main mpq (war3beta.mpq). It means that you don't need to modify official MPQs (DON'T!), you just need to use the same directory/file structure. Example: You have a file called "UI\MiscData.txt" in "War3BetaPatch.mpq" and "war3beta.mpq". Warcraft will use the one in "War3BetaPatch.mpq". If you want to modify it, just create in your "c:\war3beta\" diectory a "UI" directory and extract there the file "MiscData.txt" of your "War3BetaPatch.mpq". You can now modify it and next time you'll start War3, it'll use it instead. Warning! -In some cases, if you play with others, everybody will need to have the same modified files or you'll get an error. -Some files have a "special" format and if you modify them, you'll "falsify" this format (especialy .slk files). In some cases it will work, in some others it won't. Be aware of that 'cause War3 will try to find a "standard file" instead (one in the MPQs). - Map files (W3M Files) To edit a map, you'll have to unpack the files of the "w3m" somewhere, then modify them and finally put them back in a "w3m". W3M content: war3map.w3e war3map.w3i war3map.wtg war3map.wct war3map.wts war3map.j war3map.shd war3mapMap.tga war3mapMap.blp war3mapMap.b00 war3map.mmp war3mapPath.tga war3map.wpm war3map.doo war3mapUnits.doo war3map.w3r war3map.w3c war3map.w3u war3map.w3s war3map.imp (signature) (listfile) (attributes) We'll see now what these files stand for. 2) "war3map.j" The JASS Script This is the main map script file. You can open it with notepad. The language used is called JASS and has been developped by Blizzard. Many forums talk about theses files and how to edit them. The script file is loaded when you create a game. |
| 04-18-2002, 10:08 PM | #2 |
3) "war3map.w3e" The environment This is the tileset file. It contains all the data about the tilesets of the map. Let's say the map is divided into squares. What we call "tileset" here is just a parameter of a common corner of 4 squares (if we're not on the edge of course!). So if you want a 256x256 map, you'll have 257x257 tilesets. The first tileset stands for the lower left corner of the map looking from the top. Here is the file format: Header: 4bytes: file ID = [57 33 45 21]h = "W3E!" 4bytes: w3e format version [0B 00 00 00]h = version 11 1bytes: main tileset [TS] -TS Meaning- - A Ashenvale - B Barrens - F Lordaeron Fall - L Lordaeron Summer - N Northrend - V Village - W Lordaeron Winter - X City Dalaran - Y City Lordaeron 4bytes: [00 00 00 00]h 4bytes: number 'A' of ground tileID used (Little Endian) A*4bytes: ground tilesets IDs -TileD Meaning- - Ldrt Lords_Dirt - Ldro Lords_DirtRough - Ldrg Lords_DirtGrass - Lrok Lords_Rock - Lgrs Lords_Grass - Lgrd Lords_GrassDark - Fdrt Lordf_Dirt - Fdro Lordf_DirtRough - Fdrg Lordf_DirtGrass - Frok Lordf_Rock - Fgrs Lordf_Grass - Fgrd Lordf_GrassDark - Wdrt Lordw_Dirt - Wdro Lordw_DirtRough - Wsng Lordw_SnowGrass - Wrok Lordw_Rock - Wgrs Lordw_Grass - Wsnw Lordw_Snow - Ysqd City_SquareTiles - Yrtl City_RoundTiles - Yhdg City_GrassTrim the following has been disabled since War3 b1.10 - Bdrt Barrens_Dirt - Bdrh Barrens_RedDirt - Bdrr Barrens_Pebbles - Bdsd Barrens_DesertDark - Bdsr Barrens_Desert - Bflr Barrens_Rock - Bgrr Barrens_Grass - Ndrt North_dirt - Ndrd North_dirtdark - Nrck North_rock - Ngrs North_Grass - Nice North_ice - Nsnw North_Snow - Nsnr North_SnowRock - Ydtr City_RockyRoad - Ydrr City_Dirtroad - Ysqd City_SquareTilesDark - Ysql City_SquareTilesLight - Yblm City_BlackMarble - Yrtl City_RoundTiles - Ybtl City_BrickTiles - Ysts City_StoneSidewalk - Yglb City_GrassLongBlades - Ygsb City_GrassShortBlades - Vdrt Village_Dirt - Vmud Village_Mud - Vdrr Village_DirtRough - Vdrc Village_DirtCracked - Vrck Village_Rocks - Vcbp Village_CobblePath - Vcrp Village_Crops - Vrts Village_RoundTiles - Vstp Village_StonePath - Vgrl Village_GrassLong - Vgrs Village_GrassShort - Vgrt Village_GrassThick - Xdrt City_Dala_Dirt - Xdtr City_Dala_RockyRoad - Xdrr City_Dala_Dirtroad - Xsqd City_Dala_SquareTilesDark - Xsql City_Dala_SquareTilesLight - Xblm City_Dala_BlackMarble - Xrtl City_Dala_RoundTiles - Xbtl City_Dala_BrickTiles - Xsts City_Dala_StoneSidewalk - Xglb City_Dala_GrassLongBlades - Xgsb City_Dala_GrassShortBlades - Xhdg City_Dala_GrassHedge - Zdrt City_Lord_Dirt - Zdtr City_Lord_RockyRoad - Zdrr City_Lord_Dirtroad - Zsqd City_Lord_SquareTilesDark - Zsql City_Lord_SquareTilesLight - Zblm City_Lord_BlackMarble - Zrtl City_Lord_RoundTiles - Zbtl City_Lord_BrickTiles - Zsts City_Lord_StoneSidewalk - Zglb City_Lord_GrassLongBlades - Zgsb City_Lord_GrassShortBlades - Zhdg City_Lord_GrassHedge (refer to the files "TerrainArt\Terrain.slk" for more details) 4bytes: number 'B' of cliff tilesets used (Little Endian) B*4bytes: cliff tilesets IDs -CliffID Meaning Ground Tileset- - CLdi Lords_cliffdirt Ldrt - CLgr Lords_cliffgrass Lgrs - CFdi Lordf_cliffdirt Fdrt - CFgr Lordf_cliffgrass Fgrs - CWgr Lordw_cliffgrass Wgrs - CWsn Lordw_cliffsnow Wsnw - CBde Barrens_CliffDesert Bdsr - CBgr Barrens_CliffGrass Bgrr - CNdi North_cliffdirt Ndrt - CNsn North_cliffice Nsnw - CAgr Ashen_cliffgrass Agrs - CAdi Ashen_cliffdirt Adrt - CCgr Felwood_cliffgrass Cgrs - CCdi Felwood_cliffdirt Cdrt - CYdi City_CliffDirt Ydrt - CYsq City_CliffSquareTiles Ysqd - CVdi Village_CliffDirt Vdrt - CVgr Village_CliffGrassThick Vgrt - CXdi Dalaran_CliffDirt Xdrt - CXsq Dalaran_CliffSquareTiles Xsqd - CDdi Cave_CliffDirt Ddrt - CDsq Cave_CliffSquareTiles Dsqd the following has been disabled since War3b1.10 - CLdi Lords_cliffdirt Ldrt - CLgr Lords_cliffgrass Lgrs - CFdi Lordf_cliffdirt Fdrt - CFgr Lordf_cliffgrass Fgrs - CWgr Lordw_cliffgrass Wgrs - CWsn Lordw_cliffsnow Wsnw - CBde Barrens_CliffDesert Bdsr - CBgr Barrens_CliffGrass Bgrr - CNdi North_cliffdirt Ndrt - CNsn North_cliffice Nsnw - CAgr Ashen_cliffgrass Agrs - CAdi Ashen_cliffdirt Adrt - CCgr Felwood_cliffgrass Cgrs - CCdi Felwood_cliffdirt Cdrt - CYdi City_CliffDirt Ydrt - CYsq City_CliffSquareTiles Ysqd - CVdi Village_CliffDirt Vdrt - CVgr Village_CliffGrassThick Vgrt - CXdi Dalaran_CliffDirt Xdrt - CXsq Dalaran_CliffSquareTiles Xsqd - CZdi City_Lord_CliffDirt Zdrt - CZsq City_Lord_CliffSquareTilesDark Zsqd 4bytes: width of the map + 1 = Mx 4bytes: height of the map + 1 = My Example: - Hex Value (Mx=My=) Map Size - 91h 144x144 - A1h 160x160 4bytes: center offeset of the map X (float) 4bytes: center offeset of the map Y (float) These 2 offsets are used in the scripts files, doodads and more. The orginal (0,0) coordinate is at the bottom left of the map (looking from the top) and it's easier to work with (0,0) in the middle of the map so usually, these offsets are : -1*(Mx-1)*128/2 and -1*(My-1)*128/2 where: (Mx-1) and (My-1) are the width and the height of the map 128 is supposed to be the size of tile on the map /2 because we don't want the length but the middle. -1* because we're "translating" the center of the map, not giving it's new coordinates Data: Each tileset is defined by a block of 7 bytes. The number of blocks is equal to Mx*My. 2bytes: ground height (Little Endian) 1000h: really low 2000h: normal height (ground level 0) 3000h: really high 2byte: water level (Little Endian) + map edge boundary flag*(see notes) 4bit: flags* (see notes) 4bit: ground texture type (grass, dirt, rocks,...) 1byte: texture details (rocks, holes, bones,...) 4bit: cliff texture type 4bit: layer height *flags notes: Flags values: 0x4000 --> shadow flag on the edges of the map (non-playable area) 0x0010 --> flag used to set a ramp between two layers 0x0020 --> blight flag (ground will look like Undead's ground) 0x0040 --> water flag 0x0080 --> minimap shadow flag; used like the shadow flag but on playable area. Usually set by the World Editor "boundary" tool. The difference between the "shadow flag" and the "minimap shadow flag" are that you can't change the "shadow flag" using the world editor but the result is the same. Water level: Water level is stored just like ground height. The difference is that you have to remove the 2 highest bit (located on the seconde byte). One of these 2 bit is used for the shadow flag (boundary). Tilepoint data EXAMPLE: 43 21 75 6C C4 31 17 43 21 --(little endian)--> 0x2143 --(hex-->dec)--> height = 8515 75 6C --(little endian)--> 0x6C75 --(extract shadow flag)--> (0x6C75 & 0xC000) = 0x4000 shadow flag set --(extract water data)--> (0x6C75 & 0x3FFF) = 0x2C75 --(hex-->dec)--> water level = 11381 C4 --> C sets both water flag and minimap shadow flag, 4 means tilepoint is using ground type #4 31 --> means tilepoint is using detail texture #49 (=0x031) 17 --> 1 means cliff type #1, 7 means tilepoint on layer "7" The tilepoint "final height" you see on the WE is given by: (ground_height + layer*0x0200 - 0x2000)/4 = (0x27A4 + 0x0E00 - 0x2000)/4 = (10148 + 3584 - 8192)/4 = 1385.0 The tilepoint "water level" you see on the WE is given by: water_level/4 - 90 = 11381/4 -90 = 2755,25 In this case, water flag is set and water level is really above the ground level so we'll have really deep water. This is just an example and I don't think you can find such a tilepoint on a map. It was just for demonstration purpose. 3) "war3map.shd" The Shadow File This file has no header, only raw data. Size of the file = 16*map_width*map_height 1byte can have 2 values: 00h = no shadow FFh = shadow Each byte set the shadow status of 1/16 of a tileset. It means that each tileset is divided in 16 parts (4*4). 4) "war3mapPath.tga" The Image Path file or "war3map.wpm" The Path Map File Only one of these two file is used for pathing. Old versions (<=1.21) use the "war3mapPath.tga". Since 1.30, Warcraft 3 uses a new format instead: "war3map.wpm". 4a) "war3mapPath.tga" The Image Path file It's an standard 32bits RGB TGA file with no compression and a black alpha channel. The TGA format is really important because if Warcraft III doesn't recognise the file format, it'll do weird things on the tilesets! Don't forget the alpha channel! Each tile on the map is divided in 16 pixels (4*4 like in the shadow file), so the TGA width is 4*map_width and its height is 4*map_height. Each pixel on the TGA affects a particular part of a tileset on the map. The color of a pixel sets the rules for that part. The top left corner of the image is the upper left corner on the map. Header format (18 bytes): 1byte: ID Length = 0 1byte: Color Map Type = 0 1byte: Image Type = 2 (uncompressed RGB) -- Color Map Specification (5 bytes) -- 2bytes: First Entry Index = 0 2bytes: Color Map Length = 0 1byte: Color Map Entry Size = 0 -- Image Spec (10 bytes) -- 2bytes: X origin = 0 2bytes: Y origin = 0 2bytes: image width (little endian) 2bytes: image height (little endian) 1byte: Pixel depth = 32 (=0x20) 1byte: Image Descriptor = 0x28 (0x20=image starts from top left, 0x08=8bit for alpha chanel) Example (where "XX XX" is a width and "YY YY" a height): 00 00 02 00 00 00 00 00 00 00 00 00 XX XX YY YY 20 28 Data: One pixel is defined by 4 bytes: BB GG RR AA Where: BB is the blue value (0 or 255) GG is the green value (0 or 255) RR is the red value (0 or 255) AA is the alpha chanel value (set to 0) There are 4*4 pixels for 1 tileset. The TGA width is map_width*4. The TGA height is map_height*4. Here is the color code: Colour: Rules: White no build, no walk, no fly Red build ok, no walk, fly ok Yellow build ok, no walk, no fly Green build ok, walk ok, no fly Cyan no build, walk ok, no fly Blue no build, walk ok, fly ok Magenta no build, no walk, fly ok Black build ok, fly ok, walk ok 4b) "war3map.wpm" The Path Map File Header: 4bytes: file ID = 'MP3W' 4bytes: file version = [00 00 00 00]h 4bytes: path map width (=map_width*4) 4bytes: path map height (=map_height*4) Data: Data size: (map_height*4)*(map_with*4) bytes Bytes format: value: meaning: 08 no build, walk ok, fly ok (underwater) 0A no build, no walk, fly ok (old magenta) 40 build ok, walk ok, fly ok (old black) 48 no build, walk ok, fly ok (bad ground or relief) 4A no build, no walk, fly ok (???) CA no build, no walk, fly ok (cliff edges) CE no build, no walk, no fly (old white) flags table: bit 0: bit 1: 1=no walk bit 2: 1=no fly bit 3: 1=no build bit 4: bit 5: bit 6: ? bit 7: ? 5) "war3map.doo" The doodad file for trees The file contains the trees definitions and positions. Here is the Format: Header: 4bytes: file ID = "W3do" 4bytes: file version (Little Endian) [07 00 00 00] = version 7 4bytes: unknown 4bytes: number of trees defined (Little Endian) Data Each tree is defined by a block of 42 bytes organized like this: 4bytes: Tree ID (can be found in the file "Units\DestructableData.slk") 4bytes: Variation (little endian) 4bytes: Tree X coordinate on the map (IEEE 32bit Float) 4bytes: Tree Y coordinate on the map (IEEE 32bit Float) 4bytes: Tree Z coordinate on the map (IEEE 32bit Float) 4bytes: Tree angle (no clue about the format used) 4bytes: Tree X scale (IEEE 32bit Float) 4bytes: Tree Y scale (IEEE 32bit Float) 4bytes: Tree Z scale (IEEE 32bit Float) 1byte: Tree flags* 1byte: Tree life (integer stored in %, 100% is 0x64, 170% is 0xAA for example) 4bytes: Tree ID number in the World Editor (little endian) (each tree has a different one) *flags: 0= invisible and non-solid tree 1= visible but non-solid tree 2= normal tree (visible and solid) To sum up how it looks: tt tt tt tt vv vv vv vv xx xx xx xx yy yy yy yy zz zz zz zz aa aa aa aa xs xs xs xs ys ys ys ys zs zs zs zs ff ll dd dd dd dd where: tt: type vv: variation xx: x coordinate yy: y coordinate zz: z coordinates aa: rotation angle xs: x scale ys: y scale zs: z scale ff:unknown ll: life dd: doodad number in the editor Example (this is the second tree of Legend): 4C 54 6C 74 08 00 00 00 00 00 74 45 00 00 70 44 00 10 24 44 E5 CB 96 40 98 85 98 3F 98 85 98 3F 98 85 98 3F 02 64 8D 01 00 00 4C 54 6C 74 --> LTlt (tree type) 08 00 00 00 --> 00000008 = variation #8 (changes the shape of the tree) 00 00 74 45 --> X=3904. 00 00 70 44 --> Y=960. 00 10 24 44 --> Z=656.25 E5 CB 96 40 --> Angle (float value=4.7123895, angle=270°) 98 85 98 3F --> X_Scale=1.191577 98 85 98 3F --> Y_Scale=1.191577 98 85 98 3F --> Z_Scale=1.191577 02 --> tree is solid and selectable 64 --> life=100% of default tree life 8D 01 00 00 --> 0000018D=397, tree number 397 After the last tree definition, there are 8 bytes set to 00h. These last 8 bytes set to 0 indicate that there are no mor trees in the file so these 8 bytes are REQUIERED! |
| 04-18-2002, 10:11 PM | #3 |
6) "war3mapUnits.doo" The doodad file for items and such Not much to say about that one. It's pretty much the same structure as the previous doodad file but data blocks appear to have variable length. 7) "war3map.w3i" The info file It contains some of the info displayed when you start a game. note: W3String: these can be either "null terminated string" like in C++ or a reference to a "trigger string" also stored as a "null terminated string". Example: if you see something like "Lost Temple\0" (where '\0' is the NULL charactere 0x00) it's a NULL terminated string but if it's: "TRIGSTR_000\0" it's a trigger string. A trigger string always starts with "TRIGSTR_" followed by a number which is a reference to a string defined in the .WTS file. In this case, Warcraft will not display "TRIGSTR_000" but the string defined for this trigger sting in the .WTS file instead. See ".WTS file" for more details. Format: 4bytes: file format version [10 00 00 00]h = 16 4bytes: number of saves (map version) (little endian)(int) 4bytes: editor version (little endian) (int) W3String: trigger string 0 label (map name) W3String: trigger string 3 label (map author) W3String: trigger string 2 label (map description) W3String: trigger string 1 label (players recommended) 8*4bytes (32bytes): "Camera Bounds" as defined in the JASS file (8 IEEE 32bit Floats) 4*4bytes (16bytes): camera bounds complements* (see note 1) (4 little endian ints: A, B, C and D) 4bytes: map playable area width E* (see note 1) (Little Endian) (int) 4bytes: map playable area height F* (see note 1) (Little Endian) (int) *note 1: map width = A + E + B map height = C + F + D 4bytes: flags -0x00000001=show minimap in preview screen -0x00000002=fixed priorities -0x00000004=considered as melee map -0x00000008= -0x00000010=masked area partially visible -0x00000020=custom forces fixed player setting -0x00000040=use custom forces -0x00000080= -0x00000100= -0x00000200= -0x00000400= always set? -0x00000800=waves on cliff -0x00001000=water on rolling 1bytes: map main ground type - 1st byte Meaning - A Ashenvale - B Barrens - F Lordaeron Fall - L Lordaeron Summer - N Northrend - V Village - W Lordaeron Winter - X City Dalaran - Y City Lordaeron W3String (?): Campaign background file path (ex.: UI\Glues\Loading\Backgrounds\Campaigns\Human\Human01-CampaignBackground.mdl) W3String: Map loading screen text W3String: Map loading screen title W3String: Map loading screen subtitle W3String (?): Map loading screen glue file path (UI\Glues\Loading\LoadGlue.mdl) W3String: Prologue screen text W3String: Prologue screen title W3String: Prologue screen subtitle 4bytes: max number "MAXPL" of players (Little Endian) Then, there is MAXPL times a player data like described below. 4bytes: max number "MAXFC" of forces (Little Endian) 4bytes: Foces Flags (little endian) -0x00000001: allied (force 1) -0x00000002: allied victory -0x00000004: share vision -0x00000010: share unit control -0x00000020: share advanced unit control 4bytes: unknown integer #6 (usually [FF FF FF FF]h) Then, there is MAXFC times a force data like described below. 4bytes: unknown integer [00 00 00 00h] (EOF?) Players data format: 4bytes: unknown integer 4bytes: player type (little endian) (int) 1=Human, 2=Computer, 3=Neutral, 4=Rescuable 4bytes: player race (little endian) (int) 1=Human, 2=Orc, 3=Undead, 4=Night Elf 4bytes: 00000001 = fixed start position W3String: Player name 4bytes: Starting coordinate X (IEEE 32bit Float) 4bytes: Starting coordinate Y (IEEE 32bit Float) 4bytes: ally low priorities (little endian) (bit "x"=1 --> set for player "x") 4bytes: ally high priorities (little endian) (bit "x"=1 --> set for player "x") Forces data format: W3String: Force name 4bytes: unknown integer 4bytes: unknown integer 8] "war3map.wts" The trigger string data file Open it with notepad and you'll figure out how it works. Each trigger string is defined by a number and a value for this number. When Warcraft meets a "TRIGSTR_xxx" (where "xxx" is a number), it will look in the trigger string table to find the corresponding string and replace the trigger string by that value. Example: in the .WTS file you have: STRING 0 { Blah blah blah... } Then either in the .J, or in the .W3I, Warcraft finds a TRIGSTR_000, it'll look in the table for trigger string number 0 and it'll find that the value to use is "Blah blah blah" instead of "TRIGSTR_000". Here "STRING" is followed by the trigger string number which is supposed to be different for each trigger string, then "{" indicates the begining of the string value, "Blah blah blah..." is the value and "}" indicates the end of the trigger string definition. 9) "war3mapMap.blp" and "war3mapMap.b00" the minimap image These two files work together. The BLP file contain the JPEG header and the .B00 the JPEG raw data. BLP stands for "Blip" file which I guess is a "BLIzzard Picture". If you plan to change it, follow these steps: ------------------------------------------------------- What do you need? -know how to use a hexadecimal editor and have one -know how to use Adobe Photoshop or Corel Photopaint -be familiar with RGB, CMYB and Layers If you don't understand something in the following part, please don't ask questions. Try to find answers by yourself somewhere else, thanks. OK let's start. I'll explain all I know about it and use for example Lost Temple Minimap. 1) You have unpacked Lost Temple with WinMPQ and you have the two files war3mapMap.b00 and war3mapMap.blp. Let's have a look to the BLP: It starts with something like that: 42 4C 50 30 00 00 00 00 00 00 00 00 00 01 00 00 BLP0............ 00 01 00 00 05 00 00 00 00 00 00 00 70 02 00 00 ............p... FF D8 FF E0 00 10 4A 46 49 46 00 01 01 00 00 01 ÿØÿÃ*..JFIF...... 00 01 00 00 FF FE 00 2A 49 6E 74 65 6C 28 52 29 ....ÿþ.*Intel(R) 20 4A 50 45 47 20 4C 69 62 72 61 72 79 2C 20 76 JPEG Library, v 65 72 73 69 6F 6E 20 31 2C 35 2C 34 2C 33 36 00 ersion 1,5,4,36. Address: 00h-03h: header ID: "BLP0" 0Ch-0Fh: image width (little endian); here it's [00000100]h=256 10h-13h: image height (little endian); here it's [00000100]h=256 14h-17h: ? 1Ch-1Fh: Size S of the header (little endian); here it's [00000270]h=624bytes 20h-...: Image header. Size = S. In this case, the end of the header looks like that: E6 E7 E8 E9 EA F2 F3 F4 F5 F6 F7 F8 F9 FA FF C0 æçèéêòóôõö÷øùúÿÀ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ I don't know what is the "00" part here for. 2) Make a copy of the .B00 file and open the copy. Add S bytes at the begining of the file or at the end and move the data to the end of the file to have a blank space of S bytes in the beginig of the file. Then copy and paste the image header part of the .BLP to the blank space you've made to fill it. Save and rename the copy to "minimap.jpg" for example. 3) Open the new jpeg in your favorite image editing tool (Photoshop or Photopaint) and separate the channels in CMYK. If you use Photopaint, go to Image->Split channels to...->CMYK Then swap the yellow and the cyan channels. If you use Photopaint, go to Image->Combine channels, select the "C" one in the channel part and select the "Yellow" one in the "Images" part and do the same with the "Y" and the "cyan" image. Now, you've got the map with the correct colors. You can play with it, change stuff and do whatever you want since you have at the end a CMYK image. 4) You've now finished the new minimap you want. You've got a nice JPEG using the CMYK format. Have a look now to the blake channel. If it's completely white, you're done for part 4), go to part 5). Else, you have to make it white. Don't just use a paint tool and make it white, you'd have horrible colors! First, split the channels again and copy the black channel in the clipboard. Then substract the black channel on each channel. With Photopaint, just paste it on each channel and in the objet toolbar, select "substract" as merge mode. You can also do it by right-clicking on the object you paste and select "object properties" and choose "substract" in the "merge" list. Then Combine all objects with all channels. Clear the black channel and make it white now with any tool (brush, fill, whatever...). 5) Split again the channels of your new image if it's not already done to swap again the yellow and the cyan channels like you did before. Save your JPEG using a standard format. 6) Open you new JPEG in you hexadecimal editor. Now the hard thing is to know where the header of the JPEG ends. It can be hard to get. Usually it ends with something like "FF DA" (ÿÚ) or "FF C0" (ÿÀ). If you got hard time to know it, just download Intel JPEG Library here: http://developer.intel.com/software/...s/perflib/ijl/ Open the jpeg with it and save it to another name. Then, with the IJL file format, you'll just have to find the first "F9 FA FF C0" sequence. These bytes are the last bytes of the header. Then you just have to copy the header part into your new .BLP file starting at the address 20h (image header), get the size of the header you just paste and update it in the "size of the header" section. Try to make sure you've got the whole header in the .BLP file! 7) You need now to remove the header part from the JPEG. Don't "0" it! Remove means that you suppress these bytes; the final file size should be smaller the JPEG before. Then rename the file with the .B00 extension. You should have now a new war3mapMap.blp and a new war3mapMap.b00! Congratulation! 8] Put them back in the map and see if it's working. If you did it all right, it should work correctly. ------------------------------------------------------- 10) "war3map.mmp" The menu minimap Header: 4bytes: unknown (should be [00 00 00 00]h) 4bytes: number of datasets (Little Endian) Data: The size of a datasets is 16 bytes. 4bytes: icon type - Icons Types: - 00: gold mine - 01: house - 02: player start (cross) 4bytes: X coordinate of the icon on the map 4bytes: Y coordinate of the icon on the map - Map Coordinates: - top left: 10h, 10h - center: 80h, 80h - bottom right: F0h, F0h 4bytes: player icon color - Player Colors (BB GG RR): - 03 03 FF : red - FF 42 00 : blue - B9 E6 1C : cyan - 81 00 54 : purple - 00 FC FF : yellow - 0E 8A FE : orange - 00 C0 20 : green - B0 5B E5 : pink - 97 96 95 : light gray - F1 BF 7E : light blue - 46 62 10 : aqua - 04 2A 49 : brow 11) The others files I would just quote Yobguls here (thanks Yobguls! ;) ): war3map.w3c = Camera objects file war3map.w3r = Map/Trigger Regions file (This appears to specify regions that are used by triggers and paths, like in Starcraft maps) war3map.wtc = Triggers file (I guess this works together with the script to specify actions that get triggered when certain events occur) war3map.wtg = wtg - Another trigger file (This seems to specify the functions that get called, possibly the default functions for each trigger category) |
| 04-21-2002, 09:08 PM | #4 |
Zepir: Could you analyse the .W3U file which is not included in your current W3P file description and is not included in any Blizzard made maps. The file contains unit/building/item data and can be usefull for custom maps but so far only the World Editor can generate this file. Even on my computer Window XP runs at about 70% of the normal speed when using the world editor (1800+ Athlon XP, 256Mb ram PC2700, 32 Mb TNT 2). Maybe slower computers are unable to use it, and it is not all that userfriendly until now. Besides it would be a usefull addon for the Map Editor that is being made... I hope you will take the time. I know you are one of the best(or the best) known map editor/decoder outside Blizzard. If anyone else could analyse it for him that would be nice too. You can make great changes in the game with this W3U file in the map... |
| 05-07-2002, 05:39 PM | #5 |
I'll have a look to ".w3u" files one day, right now, I want to have a look to the "war3mapUnits.doo" first. I'm almost done with the others. I've updated .w3e, .w3i, .doo, .wts and .tga. -=Zépir oo |
| 05-09-2002, 04:22 PM | #6 |
Updated again! Mainly the .WPM format. -=Zépir oo |
| 05-09-2002, 11:05 PM | #7 |
Guest | i just started modding maps, so i made a heroe have a secundary attack much like the gaunlet 2 AI map, so you choose the type of attacks and all, but when you click on attacks and select enable "both" it gives you "attack 2 only", the other options are "none" and "attack 1 only", also when you open that gaunlets map, it has "both" enabled, so its just a glitch, can someone tell me how to edit that part of the map manually or any other fix please please I wanna make my catapult attack air too =P |
| 05-11-2002, 09:29 AM | #8 |
I think the answer to this question is in the w3u file. I think you don't need hex editing to do so, I'm quite sure you can do it using the WE and creating (or copying/modifing) a new unit. -=Zépir oo |
| 09-01-2002, 10:09 PM | #9 |
Guest | I tried to locate the flag 0x00000010 for masked area partially visible in the w3i file. If each is 4 bytes, should this be the tenth 4 digit group displayed in the hex editor when I open the file? Currently the tenth four digit group is 525F. How can I change this to deactivate the flag, and prevent partial visibility for masked areas? (Since I changed the map size, I can't edit all the map properties any more, so I wanted to try this way instead.) |
| 09-02-2002, 11:23 AM | #10 | |
In any of the W3M files, once you got a WC3String (it's a C String) you can't have "absoblute offsets" since the length of such a string is variable. So you can't tell what's the flag address in your W3I. You have to see which byte correspond to what. Then, about this (updated version): Quote:
If, for example, your flags will look like this: F1 1E 00 00 in you hex editor, read it as a little endian stored integer. So you got in fact: 00 00 1E F1 Then analyse the flags: 0x1EF1 -->binary: 0001 1110 1111 0001 -->flags: (binary= hex: meaning) 0001 0000 0000 0000= 0x1000: show water waves on rolling shores 0000 1000 0000 0000= 0x0800: show water waves on cliff shores 0000 0100 0000 0000= 0x0400: map properties menu opened at least once since map creation (?) 0000 0010 0000 0000= 0x0200: use custom upgrades 0000 0000 1000 0000= 0x0080: use custom techtree 0000 0000 0100 0000= 0x0040: use custom forces 0000 0000 0010 0000= 0x0020: fixed player setting for custom forces 0000 0000 0001 0000= 0x0010: masked area are partially visible 0000 0000 0000 0001= 0x0001: hide minimap in preview screens removing flag 0x0010: 0x1EF1 - 0x0010 = 0x1EE1 |