| 05-03-2006, 09:39 PM | #16 |
Most likelly if the world editor ever tells you that some file is corrupt, then you modiffied the map's MPQ without removing / updating (Attributes) file correctly |
| 05-03-2006, 09:57 PM | #17 | |
Quote:
I tried recreating the error again, but it's not happening--oddly enough. I made a doodad file from scratch and placed a tree and it loaded and showed up just fine. But now I'll know what to look for if it does happen again--'cause that wasn't the first time. Thanks, Vex. Update It happened again and deleting the (attributes) file fixed it... yay! |
| 05-03-2006, 11:00 PM | #18 | ||||||||
Quote:
The link you gave is in fact Zepir's old site. Unfortunately he's not around any more and has quit war3 editing. But I can see if I can get in contact with him again. Quote:
This file contains all doodads and destructables. Quote:
I guess in pre-release versions this was the case. Anyway the value doesn't have any apparent meaning, so you could simply ignore it. Quote:
The selectable flag might be set by the "Editor - selectable" field in the doodad/destructable editor. Or it it might simply be true for destructables and false for doodads. The solid flag can't be set through the standard WE i think. You'd need a hex editor to change it. Quote:
I agree that they should be called cliff doodads, and that the others shouldn't be called trees. To my knowledge the type is hardcoded though. Quote:
The documentation was created back in TFT beta times. Nowadays it should be replaced by something appropriate like "Frozen Throne expansion format". Quote:
These are guesses by observation. The first one has always been set to 0 that's why it might be Z. The others are the w3e-Coordinates of the cliff doodad, that's why they are ints and not floats. we3-Corrdinates simply use the cell-number. One cell in war3 is 32.0 units wide and high. Quote:
Only cliff doodads are in the second section, all others are in the other section. Basically the second type can't be moved freely because it requires a cliff at its position. In turn the coordinates are saved via the cell numbers. In the editor you can find out if it's a special doodad by trying to select and edit it after having placed it. Thanks for the input anyway, I'll update the docs sooner or later, or if you have time feel free to do that yourself. And I'll put add a note about the (attributes) file to the top of the file, it seems this is a common mistake that many newcomers don't know about. |
| 05-03-2006, 11:31 PM | #19 | |||||||
Quote:
Hehe.. bummer. Quote:
Yeah.. that's bugging me. A map with doodads but no item tables uses 0x07 and 0x09 for those first two unknowns, but a map with item tables uses 0x08 and 0x0b ... what's more, it doesn't even seem to depend on those values when loading the file--just when placing the doodads (if you use 0x07 and 0x08 [as the editor does when no item tables are present] but you put item tables into the structure, then it still loads perfectly fine except the doodads won't have the item tables present on them). There's alot of other stuff that seems extrenuous too... alot of integers could simply be bytes (those two, the percent chance for an item to drop, even many of the "number of (something)" properties could be one or two bytes... who's really going to have 592,240,896. If everything was stored as a set of 4 bytes then that would make sense, but even that's not the case... the Doodad file has a set of 4 bytes for the Z-scale, then follows it with 2 single bytes for the flag and life percentage, and then goes back to 4 bytes for either the table pointer or unique ID number--so it's not like keeping everything nice and uniform was a primary concern when designing this. *rant rant rant* Quote:
Ah.. I'll have to play around with that a bit more. Quote:
Hardcoded where? Can't you just give 'em whatever name you want to for the purposes of the doc? Or were the names trees and "Special" doodads obtained from a DLL or something? Quote:
Well do that! Though actually... from what I've noticed thus far, the format is the same for both RoC and TFT 1.20d. In ROC, you have to use a custom table defined on the doodad itself, but it still uses the 0xFF FF FF FF pointer thing--the file structure is exactly the same. Quote:
Oh right! I forgot that cliffs had to be aligned to a cell block while (most) other doodads can be placed (nearly) anywhere. I have another question... do you happen to know how to read floats? I learned how to do conversions of whole numbers in Assembly, but we never did quite make it to floats--just mentioned that they existed (duh!). Adding this to the documentation would be pretty darn useful--or at least a link to another site that teaches it, I couldn't find one. I'm also a little confused about the use of short integers. The doc says: Quote:
Okay.. so one byte is 8 bits. These are 2 bytes, so that's 16. Now you're reserving the top two for flags, which leaves 14. But then the third one needs to be reserved for the sign, right? Which leaves 13.. that gives range of -8192 to 8191. To reach the range stated above, you'd only be able to reserve 1 bit for a flag. I hope Blizzard's next mod-friendly game is more... mod-friendly... and less utterly confusing. |
| 05-04-2006, 12:40 AM | #20 | ||
Quote:
Sorry for the confusion, I didn't mean the names were hardcoded. I meant it's hardcoded for each doodad in which section it belongs. Quote:
Their format is equal to the format of standard C++ floats (ie 4 bytes). So you can simply obtain them by directing your file stream to a float variable. In VB it would be the data type Single. I don't know about short ints, that part of the documentation is from Zepir and I've never really had to deal with those. |
| 05-04-2006, 02:07 AM | #21 | ||
Quote:
Ah.. good idea. I'm used to doing everything by hand. Quote:
Heh.. okay. So with all this information available... what has anyone done with it? I started this the other day (and so many times before then) just in order to understand how they work--but is there really any use that we could put the information to other then creating a new World Editor? I suppose there are advantages in being able to better compress maps for play--taking out the stuff that only the editor uses... for instance, destructables could be stripped out of the war3map.doo file since they're actually created through Jass along with their item tables and such--only the cliffs and doodads need to be in there. But that seems like alot of work for something that may or may not improve performance. |
| 05-04-2006, 07:14 AM | #22 | |
Quote:
Well, there are far more interesting files than the .doo file. For example w3u/w3a... (the object definitions from the object editor). Just take Widgetizer as an example. There's a lot one could do with those files. Another use of the format specs would be a listfile generator that could find all file names of protected maps by parsing the files inside (which btw already exists). But you're right stripping out the destructables would be an option for map optimizers, I don't know if Vexorian's already does that. HeavyLocker used to strip the 0-int for the empty item table (if no tables existed in the file) by setting the file version to an earlier version (7 I think). The .imp file would be interesting for an external import manager (that would for example allow importing a whole folder structure withouth having to set the path for every single file. With some immagination I'm sure you could find a whole lot of other use cases ... |
| 05-04-2006, 10:56 AM | #23 | |
Quote:
Hrmm.. true true true. Kinda makes ya wonder why Blizzard doesn't supply any of this functionality though--those lazy bastards! |
| 07-28-2006, 01:04 PM | #24 |
war3map.wtg format for Regin of Chaos Found a few new things while I was messing with my map editor. |
| 08-08-2006, 04:53 AM | #25 |
dude i think the war3map.imp's [n] is not an int or the one that tells how many files are inside i'm not that good on data types cos im a kid 01 00 00 00 d1 00 00 00 isnt d1 a hexadecimal number and d1 00 00 00 is a long? not quite sure but d1 stands for 209 in decimal so if n is an integer would be 32 30 39 00? im not quite sure but please check it.. this is my vesion Code:
Header: int: file format version (commonly 01) int: number "n" of imported files long?: n = number of imported files Data: 1byte: tells if the path is complete or needs "war3mapImported\" (08= standard path(world editor adds war3mapImported\), 0d: custom path) String["n"]: the path inside the w3m of each imported file (like "war3mapImported\mysound.wav") Note: Any file added in the W3M and added in the .imp will NOT be removed by the World Editor each time you save your map. This file can also be found in Warcraft campaign files with the name war3campaign.imp with the only difference that the standard path for imported files is "war3campaignImported\". |
| 11-07-2006, 05:22 PM | #26 |
don't ask me why my nickname is so stupid... ehrm.. I've created a map then my hdds got formatted. Now I can't edit my map coz it was protected by vexorians 3.9d.... what would you suggest... plz write to [email protected] no i don't lie... again NO I DONT LIE :)... |
| 11-07-2006, 05:35 PM | #27 |
you don't lie! But no one can believe you anyways. IF `you´ used the 'merge' method then there is no tool available able to rebuild your GUI triggers , if you used 'Shortest names' then all the names of functions and variables are lost forever. you have options: - Edit the map in JASS completelly. - Regret not making backups of your stuff before formatting the hard drive - Try to make the map again, unless you made a lot of things, it is easy to do so , and in the process you might improve your map. - Start a new map |
| 11-07-2006, 10:13 PM | #28 | |
Quote:
Well, whenever int is used in this document we mean a 4-byte integer (= long integer). So it's not really an error. The first few paragraphs of the document should clear up any questions about data types. |
| 01-02-2007, 02:30 AM | #29 |
After messing with the war3map.doo file long enough, I found that the life value for a doodad isn't always 1-100. I would sometimes find the value -1 (ff), so my guess is that any doodad found in a war3map.doo file with the life being -1 is a doodad since doodads (non-destructables) cannot be destroyed. Also, for the 'flags' byte I sometimes found the flag to be '3'. I placed 4 trees outside camera bounds and all of those had the value '3', so my guess is 3 means that the destructable is outside of the camera bounds. |
| 01-12-2007, 09:26 AM | #30 |
I don't understand the integers, they are said to be 4 bytes in endian order. So I made this php function to convert them to integers: PHP Code:
But when the whole string converted to hex looks like 'ff ff ff ff' it is supposed to be -1. But I don't see why. Maybe you can fix my function? |